Liest Optionen aus der angegebenen Umgebungsvariablen oder Konfigurationsdatei ein Siehe Konfigurationsdateien.

Wenn Sie Kennwörter oder andere Informationen in einer Konfigurationsdatei schützen möchten, können Sie das Dienstprogramm zum Verschleiern von Dateien (dbfhide) verwenden. Siehe Dienstprogramm zum Verschleiern von Dateien (dbfhide).

Bewirkt, dass Zeichenfolgenvergleiche Akzentunterschiede zwischen Buchstaben erkennen. Z.B. ist e kleiner als é, wenn der Unicode-Kollatierungsalgorithmus (Unicode Collation Algorithm, UCA) für CHAR- oder NCHAR-Datentypen verwendet wird (siehe -z und -zn). Mit Ausnahme japanischer Datenbanken, die mit UCA-Kollatierung erstellt wurden, werden Akzente standardmäßig ignoriert (daher ist e gleich é). Wenn die Basisbuchstaben (Buchstaben ohne Akzente und entfernte Groß-/Kleinschreibung) ansonsten gleich sind, werden Akzente von links nach rechts verglichen.

Die Standardeinstellung für Berücksichtigung von Akzenten einer UCA-Kollatierung beim Erstellen einer japanischen Datenbank ist Berücksichtigung von Akzenten. Damit werden Akzentbuchstaben erkannt. Siehe Unicode-Kollatierungsalgorithmus (UCA).

Bewirkt, dass Zeichenfolgenvergleiche Akzentunterschiede zwischen Buchstaben erkennen (z.B. ist e kleiner als é), wenn der UCA für CHAR- oder NCHAR-Datentypen verwendet wird (siehe -z und -zn). Standardmäßig werden Akzente ignoriert (d.h. e ist gleich é). Wenn die Basisbuchstaben (Buchstaben mit entfernten Akzenten) ansonsten gleich sind, werden Akzente von rechts nach links verglichen, entsprechend den Regeln der französischen Sprache.

Siehe Unicode-Kollatierungsalgorithmus (UCA).

Auffüllen mit Leerzeichen in der Datenbank aktivieren.

SQL Anywhere vergleicht alle Zeichenfolgen, als ob sie eine variable Länge hätten und unter Verwendung der VARCHAR-Domäne gespeichert würden. Dies schließt Zeichenfolgenvergleiche ein, die CHAR- oder NCHAR-Spalten mit fester Länge betreffen. Überdies kürzt SQL Anywhere niemals Werte oder füllt sie mit nachgestellten Leerzeichen auf, wenn die Werte in der Datenbank gespeichert werden.

Standardmäßig behandelt SQL Anywhere Leerzeichen als signifikante Zeichen. Daher ist der Wert "a " (das Zeichen "a", gefolgt von einem Leerzeichen) nicht mit der Ein-Zeichen-Zeichenfolge "a" äquivalent. Ungleichheits-Vergleiche behandeln ebenfalls ein Leerzeichen wie jedes andere Zeichen in der Kollatierung.

Wenn das Auffüllen mit Leerzeichen aktiviert ist (die dbinit-Option -b), entspricht die Semantik von Zeichenfolgen-Vergleichen besser dem ANSI/ISO SQL-Standard. Bei aktiviertem Auffüllen mit Leerzeichen ignoriert SQL Anywhere in einem Vergleich nachgestellte Leerzeichen.

Im obenstehenden Beispiel gibt ein Gleichheitsvergleich von "a" mit "a" in einer mit Leerzeichen aufgefüllten Datenbank TRUE zurück. In einer mit Leerzeichen aufgefüllten Datenbank werden Zeichenfolgen fester Länge mit Leerzeichen aufgefüllt, wenn sie von einer Anwendung abgerufen werden. Die Verbindungsoption ansi_blanks steuert, ob die Anwendung eine Warnung über die Kürzung einer Zeichenfolge bei einer solchen Zuordnung erhält. Siehe ansi_blanks-Option.

Berücksichtigt bei allen Werten die Groß- /Kleinschreibung bei Vergleichen und Zeichenfolgenverarbeitung. Bezeichner in der Datenbank beachten die Groß-/Kleinschreibung nicht, selbst in Datenbanken, die die Groß-/Kleinschreibung beachten.

Mit Ausnahme von japanischen Datenbanken, die mit der UCA-Kollatierung erstellt wurden, ist das Standardverhalten, dass alle Vergleiche die Groß-/Kleinschreibung nicht beachten. Die Standardeinstellung für Berücksichtigung von Groß-/Kleinschreibung einer UCA-Kollatierung beim Erstellen einer japanischen Datenbank ist Berücksichtigung der Groß-/Kleinschreibung.

Datenbanken, die als QAnywhere-Serverspeicher verwendet werden, sollten die Groß-/Kleinschreibung nicht berücksichtigen.

Diese Option ist zur Kompatibilität mit dem ISO/ANSI SQL-Standard vorgesehen.

Gibt die DBA-Benutzer- ID und das Kennwort an. Wenn Sie einen neuen Namen für den DBA-Benutzer bei einer Datenbank angeben, können Sie sich nicht länger mit der Datenbank als der Benutzer "DBA" verbinden. Sie können auch ein anderes Kennwort für den DBA-Datenbankbenutzer angeben. Wenn Sie kein Kennwort angeben, wird das Standardkennwort "sql" verwendet. Wenn Sie diese Option nicht angeben, wird die Standardbenutzer-ID "DBA" mit dem Kennwort "sql" erstellt.

Beide der folgenden Befehle erstellen eine Datenbank mit einem DBA-Benutzer namens "testuser" und dem Standardkennwort "sql":

dbinit -dba testuser mydb.db

dbinit -dba testuser, mydb.db

Der folgende Befehl verwendet die Standardbenutzer-ID "DBA" mit dem Kennwort "mypwd":

dbinit -dba ,mypwd mydb.db

Der folgende Befehl ändert den Benutzer "DBA" auf "user1" mit dem Kennwort "mypwd":

dbinit -dba user1,mypwd mydb.db

Es wird empfohlen, dass das Kennwort aus 7-Bit ASCII-Zeichen besteht, weil andere Zeichen möglicherweise nicht korrekt funktionieren, wenn der Server nicht vom Zeichensatz des Clients in UTF-8 konvertieren kann.

Führt eine Vorbelegung von Speicher für die Datenbank durch. Das Vorbelegen von Speicherplatz für die Datenbank dient dazu, das Risiko der Speicherplatzknappheit auf dem Laufwerk zu vermindern, auf dem die Datenbank läuft. Überdies kann die Performance verbessert werden, indem die Menge der Daten erhöht wird, die in der Datenbank gespeichert werden können, bevor der Datenbankserver die Datenbank vergrößern muss, was ein zeitaufwändiger Vorgang sein kann.

Standardmäßig wird die size in Byte angegeben. Sie können k, m, g oder p verwenden, um Einheiten in kB, MB, GB oder Seiten anzugeben.

Gibt den Verschlüsselungsalgorithmus für die Datenbank- oder Tabellenverschlüsselung an (-et). Geben Sie -ea simple für die einfache Verschlüsselung an (nicht -ek oder -ep). Eine einfache Verschlüsselung ist gleichbedeutend mit der Verschleierung und und dient nur dazu, die Daten bei einem zufälligen Direktzugriff auf die Datenbankdatei zu verbergen, wobei das Entschlüsseln der Daten in Ihrer Datenbank mithilfe eines Festplatten-Dienstprogramms erschwert wird.

Um die Sicherheit zu erhöhen, geben Sie AES oder AES256 für starke 128-Bit- bzw. 256-Bit-Verschlüsselung an. Geben Sie AES_FIPS oder AES256_FIPS für FIPS-zertifizierte 128-Bit- bzw. 256-Bit-Verschlüsselung an. Bei starker Verschlüsselung müssen Sie auch die Option -ek oder -ep angeben. Siehe Starke Verschlüsselung.

Um eine nicht verschlüsselte Datenbank zu erstellen, geben Sie -ea none an oder Sie beziehen die Option -ea nicht ein (und geben keine der Optionen -et, -ep und -ek an).

Wenn Sie die Option -ea nicht angeben, ist das Standardverhalten wie folgt:

• -ea none, wenn -ek, -ep oder -et nicht angegeben ist
• -ea AES, wenn -ek oder -ep angegeben ist (mit oder ohne -et)
• -ea simple, wenn -et ohne -ek oder -ep verwendet wird

Algorithmusnamen berücksichtigen die Groß- und Kleinschreibung nicht.

Unter Windows Mobile werden die AES_FIPS- und AES256_FIPS-Algorithmen nur mit ARM-Prozessoren unterstützt.

Der folgende Befehl erstellt eine stark verschlüsselte Datenbank mit Angabe des Chiffrierschlüssels und des Algorithmus.

dbinit -ek "0kZ2o56AK#" -ea AES_FIPS "myencrypteddb.db"

Datenkomprimierungsprogramme können verschlüsselte Datenbankdateien nicht so stark komprimieren wie unverschlüsselte.

Gibt an, dass eine stark verschlüsselte Datenbank erstellt werden soll, wobei der Chiffrierschlüssel direkt in die Befehlszeile eingegeben wird. Die -ek-Option wird mit einem AES-Algorithmus benutzt, der optional mit der -ea-Option angegeben wird. Wenn Sie die -ek-Option ohne die -ea-Option angeben, wird standardmäßig AES verwendet.

Bei der Angabe der Option -et wird die Datenbank nicht verschlüsselt. Stattdessen wird die Tabellenverschlüsselung aktiviert. Siehe Tabellenverschlüsselung.

Gibt an, dass Sie eine stark verschlüsselte Datenbank anlegen wollen, wobei der Chiffrierschlüssel in einem Dialogfeld eingegeben wird. Diese zusätzliche Sicherheitsmaßnahme verhindert, dass der Chiffrierschlüssel in lesbarer Form angezeigt wird.

Sie müssen den Chiffrierschlüssel ein zweites Mal eingeben, um zu bestätigen, dass die erste Eingabe korrekt war. Wenn die Eingaben nicht übereinstimmen, schlägt die Initialisierung fehl.

Bei der Angabe der Option -et wird die Datenbank nicht verschlüsselt. Stattdessen wird die Tabellenverschlüsselung aktiviert.

Siehe Starke Verschlüsselung.

Aktiviert die Tabellenverschlüsselung mit dem Verschlüsselungsalgorithmus (und Schlüssel), wie für die -ea-Option angegeben. Verwenden Sie diese Option, wenn Sie verschlüsselte Tabellen anstelle einer Verschlüsselung der Datenbank erstellen möchten. Wenn Sie -et mit -ek oder -ep, aber nicht -ea eingeben, wird der AES-Algorithmus standardmäßig benutzt. Wenn Sie nur die Option -et angeben, wird die einfache Verschlüsselung verwendet.

Ein Aktivieren der Tabellenverschlüsselung bedeutet nicht, dass Ihre Tabellen verschlüsselt sind. Sie müssen die Tabellen einzeln nach der Datenbankerstellung verschlüsseln. Siehe Tabelle verschlüsseln.

Wenn die Tabellenverschlüsselung aktiviert ist, werden Tabellenseiten für die verschlüsselte Tabelle, zugeordnete Indexseiten und Seiten der temporären Tabelle ebenso verschlüsselt wie Transaktionslogseiten, die Transaktionen von verschlüsselten Tabellen enthalten.

Das folgende Beispiel erstellt die Datenbank new.db, bei der die starke Verschlüsselung für Tabellen aktiviert ist, wobei der Schlüssel "abc" und der AES_FIPS-Verschlüsselungsalgorithmus verwendet werden:

dbinit -et -ek abc -ea AES_FIPS new.db

Schließt jConnect-Systemobjekte aus der Datenbank aus. Wenn Sie den jConnect JDBC-Treiber verwenden wollen, um auf Systemkatalog-Informationen zuzugreifen, müssen Sie die jConnect-Katalogunterstützung installieren (wird standardmäßig installiert). Wenn Sie diese Option angeben, können Sie weiterhin JDBC verwenden, solange Sie nicht auf Systeminformationen zugreifen. Auf Wunsch können Sie die jConnect-Unterstützung zu einem späteren Zeitpunkt mit Sybase Central oder der Anweisung ALTER DATABASE hinzufügen.

Siehe jConnect-Systemobjekte in einer Datenbank installieren.

Wenn Sie eine Datenbank für die Verwendung in Windows Mobile erstellen, finden Sie weitere Hinweise unter jConnect unter Windows Mobile.

Listet die verfügbaren Zeichensatzkodierungen auf und stoppt dann. Es wird keine Datenbank erstellt. Jede Zeichensatzkodierung wird durch eine oder mehrere Bezeichnungen (Labels) gekennzeichnet. Es gibt Zeichenfolgen, mit denen die Kodierung gekennzeichnet werden kann. Jede Zeile im angezeigten Text listet das Kodierungslabel und alternative Bezeichnungen auf, anhand derer die Kodierung identifiziert werden kann. Diese Bezeichnungen gehören zu einer von mehreren allgemeinen Kategorien: SA (das SQL Anywhere-Label), IANA (Internet Assigned Numbers Authority), MIME (Multipurpose Internet Mail Extensions), ICU (International Components for Unicode), JAVA oder ASE (Adaptive Server Enterprise).

Um eine Liste von Zeichensatzkodierungen mit den alternativen Bezeichnungen anzuzeigen, geben Sie die Option -le+ an.

Wenn das dbinit-Dienstprogramm die Zeichensatzkodierung ausgibt, handelt es sich immer um die SQL Anywhere-Version des Labels. Beispiel: Der folgende Befehl gibt die CHAR-Zeichensatzkodierung windows-1250 zurück:

dbinit -ze cp1250 -z uca test.db

Gibt die Seitengröße für die Datenbank an. Die Seitengröße (in Byte) kann für eine Datenbank 2048, 4096, 8192, 16384 oder 32768 betragen, wobei 4096 der Standardwert ist. Verwenden Sie k, um die Einheit KByte festzulegen (zum Beispiel -p 4k).

Größere Seiten bringen im Allgemeinen bei großen Datenbanken Vorteile. So ist zum Beispiel die Anzahl der zum Durchsuchen einer Tabelle erforderlichen I/O-Vorgänge geringer, weil jeweils eine ganze Seite eingelesen wird. Es gibt bei großen Seiten allerdings zusätzliche Speicheranforderungen. Es wird dringend empfohlen, dass Sie die Performance testen (und sonstige Tests durchführen), wenn Sie eine Seitengröße wählen. Danach wählen Sie die kleinste Seitengröße, die zufriedenstellende Ergebnisse liefert. Für die meisten Anwendungen sind Seitengrößen von 16 kB oder 32 kB nicht zu empfehlen. Verwenden Sie keine Seitengrößen von 16 KByte oder 32 KByte in Produktionssystemen, außer wenn Sie sicher sind, dass stets ein großer Datenbankserver-Cache verfügbar ist, und wägen Sie die Vor- und Nachteile für Speicher und Festplattenbelegung bzw. für die Performance-Eigenschaften gegeneinander ab. Wenn eine große Anzahl von Datenbanken auf einem Server gestartet wird, sollten Sie eine angemessene Seitengröße wählen.

Siehe:

• Angemessene Seitengröße verwenden

Fügt globale Prüfsummen hinzu (eine Prüfsumme wird jeder Datenbankseite hinzugefügt). Standardmäßig ist diese Option aktiviert. Mit Prüfsummen kann festgestellt werden, ob eine Datenbankseite auf der Festplatte geändert wurde. Wenn Sie eine Datenbank mit aktivierten globalen Prüfsummen erstellen, berechnet das System eine Prüfsumme, direkt bevor eine Datenbankseite auf die Festplatte geschrieben wird. Wenn die Seite von der Festplatte gelesen wird, ermittelt das System die Prüfsumme erneut und vergleicht sie mit dem auf der Seite gespeicherten Wert. Wenn die Prüfsummen unterschiedlich sind, wurde die Seite auf der Festplatte geändert oder beschädigt und ein Fehler tritt auf. Bei kritischen Datenbankseiten werden immer Prüfsummen durch den Datenbankserver berechnet, unabhängig vom Wert der Option -s.

Prüfsummen sind für Datenbanken automatisch aktiviert, die auf Windows Mobile und bestimmten Speichermedien wie z.B. Wechseldatenträgern laufen, damit eine Früherkennung von möglichen Datenbankbeschädigungen möglich ist.

Wenn eine Datenbank mit deaktivierten globalen Prüfsummen erstellt wird, können Sie Seiten, während sie geschrieben werden, weiterhin mit der Option -wc oder der START DATABASE-Anweisung Prüfsummen hinzufügen. Siehe Erkennung von Beschädigungen mithilfe von Prüfsummen.

Gibt den Namen der Transaktionslogdatei an. Das Transaktionslog ist eine Datei, in der der Datenbankserver alle von allen Benutzern durchgeführten Änderungen protokolliert. Hierbei ist es gleichgültig, welche Anwendung verwendet wird. Das Transaktionslog spielt eine entscheidende Rolle beim Sichern und Wiederherstellen sowie bei der Datenreplikation. Wenn der Dateiname keinen Pfad hat, wird es in dasselbe Verzeichnis wie die Datenbankdatei platziert. Wenn Sie dbinit ausführen, ohne die Option -t oder -n anzugeben, wird ein Transaktionslog mit demselben Dateinamen wie die Datenbankdatei erstellt, jedoch mit der Erweiterung .log.

Siehe Das Transaktionslog.

Gibt die Kollatierungssequenz für die Datenbank an. Die Kollatierungssequenz wird zum Sortieren und Vergleichen von Zeichendatentypen (CHAR, VARCHAR und LONG VARCHAR) verwendet. Die Kollatierung liefert Zeichenvergleichs- und Sortierinformationen für die verwendete Kodierung (Zeichensatz). Es ist wichtig, dass Sie Ihre Kollatierung mit Umsicht auswählen. Sie kann nach der Erstellung der Datenbank nicht mehr geändert werden, außer durch Entladen und Neuladen der Datenbank. Wenn keine Kollarierung angegeben ist, verwendet SQL Anywhere eine auf Betriebssystemsprache und Zeichensatz basierende Kollatierung. Siehe:

• Hinweise zur Kollatierung
• Empfohlene Zeichensätze und Kollatierungen
• Unterstützte und alternative Kollatierungen

Optional können Sie Optionen für Kollatierungsanpassungen (collation-tailoring-string) für eine zusätzliche Steuerung bei Zeichensortierungen und -vergleichen angeben. Diese Optionen werden in der Form von Schlüsselwort=Wert-Paaren, die in Klammern gesetzt werden, hinter dem Kollatierungsnamen angegeben. Zum Beispiel:

dbinit -c -z uca(locale=es;case=LowerFirst) spanish2.db

Siehe Optionen für Kollatierungsanpassungen.

In der collation-tailoring-string angegebene Einstellungen für Groß- und Kleinschreibung sowie Akzente heben die entsprechenden Optionen für dbinit (-c, -a und -af) auf, falls Sie beides angeben.

Gibt die Kodierung für die Kollatierung an. Die meisten mit -z angegebenen Kollatierungen legen sowohl die Kodierung (Zeichensatz) als auch die Reihenfolge fest. Bei diesen Kollatierungen sollte Option -ze nicht angegeben werden.

Wenn die von der Option -z angegebene Kollatierung UCA(Unicode Collation Algorithm) ist, kann die Option -ze UTF-8 oder eine beliebige Einbyte-Kodierung für CHAR-Datentypen angeben. Standardmäßig verwendet SQL Anywhere UTF-8. Verwenden Sie die Option -ze, damit eine sprachumgebungsspezifische Kodierung festgelegt und die Vorteile des UCAs bei Vergleichen und Sortierungen erhalten beleiben.

Gibt die Kollatierungssequenz, die zum Sortieren und Vergleichen von nationalen Zeichendatentypen (NCHAR, NVARCHAR und LONG NVARCHAR) verwendet wird, an. Die Kollatierung liefert Zeichen-Sortierinformationen für die verwendete UTF-8-Kodierung (Zeichensatz). Werte sind UCA (Standardwert) oder UTF8BIN. Mit UTF8BIN wird eine binäre Sortierung aller Zeichen erstellt, deren Kodierung größer als 0x7E ist. Wenn die DLLs dbicu12 und dbicudt12 nicht installiert sind, ist die NCHAR-Standardkollatierung UTF8BIN. Siehe Hinweise zur Kollatierung.

Optional können Sie Optionen für Kollatierungsanpassungen (collation-tailoring-string) für eine zusätzliche Steuerung bei Zeichensortierungen und -vergleichen angeben. Diese Optionen werden in der Form von Schlüsselwort=Wert-Paaren, die in Klammern gesetzt werden, hinter dem Kollatierungsnamen angegeben. Zum Beispiel:

dbinit -c -zn UCA(case=LowerFirst) sens.db

Siehe Optionen für Kollatierungsanpassungen.

In der collation-tailoring-string angegebene Einstellungen für Groß- und Kleinschreibung sowie Akzente heben die entsprechenden Optionen für dbinit (-c, -a und -af) auf, falls Sie beides angeben.