Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Deutsch) » SQL Anywhere Server - SQL-Referenzhandbuch » Verwendung von SQL » SQL-Anweisungen » SQL-Anweisungen (A-D)

 

CREATE DATABASE-Anweisung

Mit dieser Anweisung erstellen Sie eine Datenbank. Sie wird als Betriebssystemdatei gespeichert.

Syntax
CREATE DATABASE DB-Dateiname-Zeichenfolge [ Erstellungsoption ... ]
Erstellungsoption : 
   [ ACCENT { RESPECT | IGNORE | FRENCH } ]
   [ ASE [ COMPATIBLE ] ]
   [ BLANK PADDING { ON | OFF } ]
   [ CASE { RESPECT | IGNORE } ]
   [ CHECKSUM { ON | OFF } ]
   [ COLLATION Kollatierungsbez[ ( Kollatierungsanpassung-Zeichenfolge ) ] ]
   [ DATABASE SIZE  Größe { KB | MB | GB | PAGES | BYTES } ]
   [ DBA USER Benutzer_ID ]
   [ DBA PASSWORD Kennwort ]
   [ ENCODING Kodierungsbez ]
   [ ENCRYPTED [ TABLE ] { Algorithmus_Schlüssel_Angabe | OFF } ]
   [ JCONNECT { ON | OFF } ]
   [ PAGE SIZE Seitengröße ]
   [ NCHAR COLLATION nchar_Kollatierungsbez[ ( Kollatierungsanpassung-Zeichenfolge ) ] ]
   [ [ TRANSACTION ] { LOG OFF | LOG ON [ Logdateiname_Zeichenfolge ]
       [ MIRROR Spiegeldateiname_Zeichenfolge ] } ]
Seitengröße :
2048 | 4096 | 8192 | 16384 | 32768
Algorithmus_Schlüssel_Angabe:
ON
| [ ON ] KEY Schlüssel [ ALGORITHM AES-Algorithmus ]
| [ ON ] ALGORITHM AES-Algorithmus KEY Schlüssel
| [ ON ] ALGORITHM 'SIMPLE'
AES-Algorithmus : 
'AES' | 'AES256' | 'AES_FIPS' | 'AES256_FIPS'
Schlüssel: Zeichenfolge in Anführungszeichen
Parameter

Die Dateinamen (DB-Dateiname-Zeichenfolge, Logdateiname_Zeichenfolge und Spiegeldateiname_Zeichenfolge) sind Zeichenfolgen, die Betriebssystem-Dateinamen enthalten. Als Literal-Zeichenfolgen müssen sie von Apostrophen umschlossen sein.

  • Wenn Sie einen Suchpfad angeben, muss jedes Backslashzeichen (\), auf das ein n oder ein x folgt, verdoppelt werden. Dadurch wird vermieden, dass es als Zeilenendmarke (\n) oder als Hexadezimalzahl (\x) entsprechend den Regeln für Zeichenfolgen in SQL betrachtet wird.

    Es ist immer sicherer, dem Backslashzeichen ein Escapezeichen voranzustellen. Zum Beispiel:

    CREATE DATABASE 'c:\\databases\\my_db.db'
    LOG ON 'e:\\logdrive\\my_db.log';
  • Wenn Sie keinen Suchpfad oder nur einen relativen Suchpfad angeben, wird die Datenbank relativ zum Arbeitsverzeichnis des Datenbankservers erstellt. Wenn Sie keinen Suchpfad für eine Transaktionslogdatei angeben, wird die Datei in demselben Verzeichnis erstellt wie die Datenbankdatei. Es wird empfohlen, dass Sie die Datenbankdatei und das Transaktionslog auf getrennten Datenträgern auf dem Computer speichern.

  • Wenn Sie keine Dateierweiterung angeben, wird eine Datei mit der Erweiterung .db für Datenbanken, .log für das Transaktionslog und .mlg für den Transaktionslogspiegel erstellt.

Sie können nicht utility_db als DB-Dateiname-Zeichenfolge eingeben. Dieser Name ist für die Dienstprogrammdatenbank reserviert. Weitere Hinweise finden Sie unter Die Dienstprogrammdatenbank verwenden.

  • ACCENT-Klausel   Diese Klausel wird benutzt, um die Berücksichtigung von Akzenten in der Datenbank festzulegen. Die Unterstützung für diese Klausel ist veraltet. Verwenden Sie die Optionen für die Kollatierungsanpassung in den Klauseln COLLATION und NCHAR COLLATION, um die Berücksichtigung von Akzenten festzulegen.

    Die ACCENT-Klausel gilt nur, wenn der UCA-Algorithmus (Unicode Collation Algorithm) für die Kollatierung verwendet wird, die in der COLLATION- oder NCHAR COLLATION-Klausel angegeben ist. ACCENT RESPECT bewirkt, dass beim UCA-Zeichenfolgenvergleich Akzentunterschiede bei den Buchstaben beachtet werden. Beispiel: "e" ist weniger als "é". ACCENT FRENCH ist ähnlich wie ACCENT RESPECT, nur dass Akzente von rechts nach links verglichen werden, entsprechend den Regeln der französischen Sprache. ACCENT IGNORE bewirkt, dass Akzente bei Zeichenfolgenvergleichen ignoriert werden. Beispiel: "e" ist gleich "é".

    Wenn die Berücksichtigung von Akzenten beim Erstellen der Datenbank nicht aktiviert wurde, ist der Standardwert für die Berücksichtigung von Akzenten für Vergleiche und Sortierungen auf Insensitiv eingestellt, wobei aber eine Ausnahme gilt: Bei japanischen Datenbanken, die mit der UCA-Kollatierung erstellt wurden, wird die Berücksichtigung von Akzenten standardmäßig auf Sensitiv eingestellt.

    Weitere Hinweise zu Zeichensätzen finden Sie unter Internationale Sprachen und Zeichensätze.

  • ASE COMPATIBLE-Klausel   Erstellen Sie weder SYS.SYSCOLUMNS- noch SYS.SYSINDEXES-Ansichten. Standardmäßig werden diese Ansichten aus Kompatibilitätsgründen mit Systemtabellen erstellt, die in Watcom SQL (Softwareversion 4 und früher) verfügbar sind. Diese Anzeigen kollidieren mit den Sybase Adaptive Server Enterprise-Kompatibilitätsansichten dbo.syscolumns und dbo.sysindexes.

  • BLANK PADDING-Klausel   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 (durch Angabe von PADDING ON), befolgt die Semantik von Zeichenfolgenvergleichen eher den 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. Ob die Anwendung bei so einer Zuordnung eine Zeichenfolge-Kürzungswarnung erhält, hängt von der Einstellung der Verbindungsoption ansi_blanks ab. Weitere Hinweise finden Sie unter ansi_blanks-Option [Kompatibilität].

  • CASE-Klausel   Diese Klausel wird benutzt, um die Berücksichtigung von Groß- und Kleinschreibung in der Datenbank festzulegen. Die Unterstützung für diese Klausel ist veraltet. Verwenden Sie die Optionen für die Kollatierungsanpassung in den Klauseln COLLATION und NCHAR COLLATION, um die Berücksichtigung von Groß- und Kleinschreibung festzulegen.

    CASE RESPECT bewirkt, dass die Groß-/Kleinschreibung bei Zeichenfolgenvergleichen in Bezug auf alle CHAR- und NCHAR-Datentypen berücksichtigt wird. Vergleiche mit UCA berücksichtigen die Groß-/Kleinschreibung eines Buchstabens nur, wenn die Basisbuchstaben und Akzente gleich sind. Bei allen anderen Kollatierungen wird zwischen Groß- und Kleinbuchstaben unterschieden. So ist beispielsweise a kleiner als A, dies wiederum kleiner als b, und so weiter. CASE IGNORE bewirkt Zeichenfolgenvergleiche ohne Berücksichtigung der Groß-/Kleinschreibung. Groß- und Kleinbuchstaben werden als exakt gleich angesehen.

    Wenn die Berücksichtigung von Groß- und Kleinschreibung beim Erstellen der Datenbank nicht aktiviert wurde, ist der Standardwert für die Berücksichtigung von Groß- und Kleinschreibung für Vergleiche und Sortierungen auf Insensitiv eingestellt, wobei aber eine Ausnahme gilt: Bei japanischen Datenbanken, die mit der UCA-Kollatierung erstellt wurden, wird die Berücksichtigung von Groß- und Kleinschreibung standardmäßig auf Sensitiv eingestellt.

    CASE RESPECT ist zur Gewährleistung der Kompatibilität mit dem ISO/ANSI SQL-Standard vorgesehen. Bezeichner in der Datenbank berücksichtigen die Groß-/Kleinschreibung niemals, selbst in Datenbanken nicht, in denen die Groß-/Kleinschreibung beachtet wird.

    Weitere Hinweise zu Zeichensätzen finden Sie unter Internationale Sprachen und Zeichensätze.

  • CHECKSUM-Klausel   Mit Prüfsummen kann festgestellt werden, ob eine Datenbankseite auf der Festplatte geändert wurde. Wenn Sie eine Datenbank mit aktivierten 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 und ein Fehler tritt auf. Datenbanken, die mit aktivierten Prüfsummen erstellt wurden, können auch mithilfe von Prüfsummen validiert werden. Sie können überprüfen, ob eine Datenbank mit aktivierten Prüfsummen erstellt wurde, indem Sie die folgende Anweisung ausführen:
    SELECT DB_PROPERTY ( 'Checksum' );

    Diese Abfrage gibt ON zurück, wenn Prüfsummen aktiviert sind, sonst wird OFF zurückgegeben. Prüfsummen sind standardmäßig deaktiviert. Wird die CHECKSUM-Klausel weggelassen, wird also OFF angewendet.

    Ungeachtet der Einstellung dieser Klausel aktiviert der Datenbankserver Prüfsummen immer für Datenbanken, die auf Speichermedien wie beispielsweise Wechseldatenträgern laufen, sowie für Datenbanken, die unter Windows Mobile ausgeführt werden, damit eine frühe Erkennung von Beschädigungen der Datenbankdatei möglich ist. Er berechnet auch Prüfsummen für kritische Seiten während der Validierung. Weitere Hinweise finden Sie unter Prüfsummen zur Erkennung von Beschädigungen verwenden, Validierungs-Dienstprogramm (dbvalid), sa_validate-Systemprozedur oder VALIDATE-Anweisung.

  • COLLATION-Klausel   Die durch die COLLATION-Klausel angegebene Kollatierung wird für die Sortierung und den Vergleich von Zeichendatentypen verwendet (CHAR, VARCHAR und LONG VARCHAR). Die Kollatierung liefert Zeichenvergleichs- und Sortierinformationen für die verwendete Kodierung (Zeichensatz). Wenn die COLLATION-Klausel nicht angegeben ist, wählt SQL Anywhere eine Kollatierung basierend auf der Betriebssystemsprache und Kodierung aus.

    Die Kollatierung kann aus der Liste der Kollatierungen ausgewählt werden, die den SQL Anywhere Collation Algorithm verwenden, oder sie kann eine UCA-Kollatierung (Unicode Collation Algorithm) sein. Wenn UCA angegeben wird, sollten Sie auch die ENCODING-Klausel angeben.

    Es ist wichtig, dass Sie Ihre Kollatierung mit Umsicht auswählen. Sie kann nicht mehr geändert werden, nachdem die Datenbank erstellt wurde. Weitere Hinweise finden Sie unter Kollatierungen wählen.

    Eine Liste der unterstützten Kollatierungen finden Sie unter Empfohlene Zeichensätze und Kollatierungen und Unterstützte und alternative Kollatierungen.

    Optional können Sie Optionen für Kollatierungsanpassungen (Kollatierungsanpassung-Zeichenfolge) 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 Kollatierung-Namen angegeben. Zum Beispiel, ... CHAR COLLATION 'UCA(locale=es;case=respect;accent=respect)'.

  • DATABASE SIZE-Klausel   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 zeitaufwendiger Vorgang sein kann. Verwenden Sie KB, MB, GB oder PAGES, um die Einheit in KByte, MByte, GByte oder Seiten anzugeben.

  • DBA USER-Klausel   Verwenden Sie diese Klausel, um einen DBA-Benutzer für die Datenbank anzugeben. Wenn Sie diese Klausel verwenden, können Sie keine Datenbankverbindung mehr als standardmäßiger DBA-Benutzer herstellen. Wenn Sie diese Klausel nicht angeben, wird die ID für den standardmäßigen DBA-Benutzer erstellt.

  • DBA PASSWORD-Klausel   Sie können ein anderes Kennwort für den DBA-Datenbankbenutzer angeben. Wenn Sie diese Klausel nicht angeben, wird für den DBA-Benutzer das Standardkennwort (sql) verwendet.

  • ENCODING-Klausel   Die meisten in der COLLATION-Klausel angegebenen Kollatierungen legen sowohl die Kodierung (Zeichensatz) als auch die Sortierreihenfolge fest. Bei diesen Kollatierungen sollte die ENCODING-Klausel nicht angegeben werden. Wenn jedoch der in der COLLATION-Klausel angegebene Wert UCA (Unicode Collation Algorithm) ist, verwenden Sie die ENCODING-Klausel, um eine standortspezifische Kodierung anzugeben und die Vorteile von UCA bei Vergleichen und Sortierungen zu nutzen. Die ENCODING-Klausel kann UTF-8 oder jede Einbyte-Kodierung für CHAR-Datentypen angeben. Sie darf keine andere Mehrbyte-Kodierung als UTF-8 angeben.

    Wenn Sie die UCA-Kollatierung auswählen, können Sie Optionen der Kollatierungsanpassung festlegen. Weitere Hinweise finden Sie unter Optionen für Kollatierungsanpassungen.

    Wenn COLLATION auf UCA eingestellt ist und ENCODING nicht angegeben wurde, verwendet SQL Anywhere UTF-8. Weitere Hinweise zu den empfohlenen Kodierungen und Kollatierungen finden Sie unter Empfohlene Zeichensätze und Kollatierungen.

    Weitere Hinweise zum Bezug der Liste der von SQL Anywhere unterstützten Kodierungen finden Sie unter Unterstützte Zeichensätze.

  • ENCRYPTED- oder ENCRYPTED TABLE-Klausel   Eine Verschlüsselung macht gespeicherte Daten unlesbar. Verwenden Sie das ENCRYPTED-Schlüsselwort (ohne TABLE), um die gesamte Datenbank zu verschlüsseln. Verwenden Sie die ENCRYPTED TABLE-Klausel, wenn Sie nur die Tabellenverschlüsselung aktivieren wollen. Die Tabellenverschlüsselung zu aktivieren heißt, dass die Tabellen, die nachfolgend unter Verwendung der ENCRYPTED-Klausel erstellt oder geändert werden, unter Verwendung der Einstellungen verschlüsselt werden, die Sie bei der Datenbankerstellung angegeben haben. Weitere Hinweise finden Sie unter Tabellenverschlüsselung.

    Es gibt zwei Arten von Datenbank- und Tabellenverschlüsselung: einfache und starke. Einfache Verschlüsselung entspricht der Verschleierung. Die Daten sind unlesbar, aber eine Person mit kryptografischen Kenntnissen könnte die Daten entziffern. Bei starker Verschlüsselung sind die Daten unlesbar und es ist nahezu unmöglich, sie zu entziffern.

    Für eine einfache Verschlüsselung geben Sie ENCRYPTED ON ALGORITHM SIMPLE bzw. ENCRYPTED ALGORITHM SIMPLE an, oder Sie geben die ENCRYPTED ON-Klausel ohne Festlegung eines Algorithmus bzw. Schlüssels an.

    Um die starke Verschlüsselung zu aktivieren, geben Sie ENCRYPTED ON ALGORITHM mit einem 128- oder 256-Bit-Algorithmus und die KEY-Klausel zur Definition eines Chiffrierschlüssels an. Es wird empfohlen, dass Sie einen Wert für Ihren Schlüssel wählen, der mindestens 16 Zeichen umfasst und eine Mischung aus Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen enthält.

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

    Achtung

    Bei stark verschlüsselten Datenbanken achten Sie darauf, eine Kopie des Schlüssels an einem sicheren Ort zu verwahren. Wenn Sie den Chiffrierschlüssel verlieren, gibt es keine Möglichkeit, auf die Daten zuzugreifen, auch nicht mit der Unterstützung des technischen Kundendiensts. Die Datenbank muss verworfen und eine neue Datenbank muss erstellt werden.

    Weitere Informationen zur starken Datenbankverschlüsselung finden Sie unter Starke Verschlüsselung.

    Sie können auch eine verschlüsselte Kopie einer bestehenden Datenbank mit der Anweisung CREATE ENCRYPTED DATABASE erstellen. Weitere Hinweise finden Sie unter CREATE ENCRYPTED DATABASE-Anweisung.

  • JCONNECT-Klausel   Um dem jConnect JDBC-Treiber den Zugriff auf Systemkataloginformationen zu ermöglichen, geben Sie JCONNECT ON an. Dies installiert die Systemobjekte, die jConnect-Unterstützung bereitstellen. Stellen Sie JCONNECT OFF ein, wenn Sie die jConnect-Systemobjekte ausschließen möchten. Sie können trotzdem JDBC verwenden, sofern Sie nicht auf Systemdaten zugreifen. JCONNECT ist standardmäßig ON.

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

  • NCHAR COLLATION-Klausel   Die durch die NCHAR COLLATION-Klausel angegebene Kollatierung wird für die Sortierung und den Vergleich von nationalen Zeichendatentypen verwendet (NCHAR, NVARCHAR und LONG NVARCHAR). Die Kollatierung liefert Informationen über die Zeichensortierfolge für die UTF-8-Kodierung (Zeichensatz), die für nationale Sonderzeichen verwendet wird. Wenn die NCHAR COLLATION-Klausel nicht angegeben ist, verwendet SQL Anywhere UCA (Unicode Collation Algorithm). Die einzige andere zulässige Kollatierung ist UTF8BIN, die eine binäre Sortierreihenfolge für alle Zeichen erstellt, deren Kodierung größer als 0x7E ist. Weitere Hinweise finden Sie unter Kollatierungen wählen.

    Optional können Sie Optionen für Kollatierungsanpassungen (Kollatierungsanpassung-Zeichenfolge) für eine zusätzliche Steuerung bei Zeichensortierungen und -vergleichen angeben. Diese Optionen nehmen die Form von Schlüsselwort=Wertepaare an, in Apostrophe gesetzt und dem Kollatierung-Namen folgend. Zum Beispiel: ... NCHAR COLLATION 'UCA(locale=es;case=respect;accent=respect)'. Wenn Sie die ACCENT- oder die CASE-Klausel und eine Zeichenfolge für Kollatierungsanpassungen angeben, die Angaben für die Berücksichtigung von Akzenten oder der Groß-/Kleinschreibung enthält, werden die Werte der ACCENT- und CASE-Klausel nur als Standardwerte verwendet.

    Eine Liste der unterstützten Optionen der Kollatierungsanpassung finden Sie unter Optionen für Kollatierungsanpassungen.

    Hinweis

    Wenn Sie eine UCA-Kollatierung angeben, werden alle Optionen der Kollatierungsanpassung unterstützt. Bei allen anderen Kollatierungen wird nur die Kollatierungsanpassungs-Option für Groß-/Kleinschreibung unterstützt.

    Hinweis

    Mit Optionen für Kollatierungsanpassungen erstellte Datenbanken können nicht mit einem Datenbankserver vor Version 10.0.1 gestartet werden.

  • PAGE SIZE-Klausel   Die Seitengröße für eine Datenbank kann 2.048, 4.096, 8.192, 16.384 oder 32.768 Byte betragen. Die Standard-Seitengröße ist 4096 Byte. Große Datenbanken haben bei einer höheren Seitengröße eine bessere Performance, mit hohen Seitengrößen kann aber auch ein zusätzlicher Overhead verbunden sein.

    Zum Beispiel:

    CREATE DATABASE 'c:\\databases\\my_db.db'
    PAGE SIZE 4096;
    Größe der Seiten begrenzen

    Die Seitengröße kann nicht größer sein als die vom aktuellen Server verwendete Seitengröße. Die Seitengröße des Servers wird aus der ersten der geladenen Datenbanken übernommen oder mit der Option -gp in der Serverbefehlszeile festgelegt. Weitere Hinweise finden Sie unter Serveroption -gp.

  • TRANSACTION LOG-Klausel   Das Transaktionslog ist eine Datei, in welcher der Datenbankserver alle Änderungen protokolliert, die in der Datenbank gemacht wurden. Das Transaktionslog spielt eine entscheidende Rolle beim Sichern und Wiederherstellen sowie bei der Datenreplikation.

    Mit der MIRROR-Klausel der TRANSACTION-Klausel können Sie einen Dateinamen angeben, wenn Sie einen Transaktionslogspiegel verwenden wollen. Ein Transaktionslogspiegel ist eine identische Kopie eines Transaktionslogs, die normalerweise auf einem getrennten Medium gehalten wird, um die Daten besser zu schützen. Standardmäßig verwendet SQL Anywhere keinen Transaktionslogspiegel.

Bemerkungen

Erstellt eine Datenbankdatei mit den angegebenen Namen und Attributen Diese Anweisung wird in Prozeduren, Triggern, Ereignissen oder Batches nicht unterstützt.

Berechtigungen

Die für die Ausführung dieser Anweisung erforderlichen Berechtigungen werden in der Befehlszeile des Servers mit der Befehlszeilenoption -gu eingerichtet. Als Standardeinstellung ist die DBA-Berechtigung erforderlich.

Das Konto, unter dem der Datenbankserver läuft, muss über eine Schreibberechtigung für die Verzeichnisse verfügen, in denen die Dateien erstellt werden.

Nebenwirkungen

Eine Betriebssystemdatei wird erstellt.

Siehe auch
Standards und Kompatibilität
  • SQL/2003   Erweiterung des Herstellers

Beispiele

Die folgende Anweisung erstellt eine Datenbankdatei mit dem Namen mydb.db im Verzeichnis C:\.

CREATE DATABASE 'C:\\mydb.db'
TRANSACTION LOG ON
CASE IGNORE
PAGE SIZE 4096
ENCRYPTED OFF
BLANK PADDING OFF;

Die folgende Anweisung erstellt eine Datenbank mithilfe von Codepage 1252 und verwendet UCA für CHAR- und NCHAR-Datentypen. Akzente sowie Groß-/Kleinschreibung werden bei Vergleich und Sortierung berücksichtigt.

CREATE DATABASE 'c:\\uca.db'
COLLATION 'UCA'
ENCODING 'CP1252'
NCHAR COLLATION 'UCA'
ACCENT RESPECT
CASE RESPECT;

Die folgende Anweisung erstellt die Datenbank myencrypteddb.db, die mit einfacher Verschlüsselung verschlüsselt ist:

CREATE DATABASE 'myencrypteddb.db' 
ENCRYPTED ON;

Die folgende Anweisung erstellt die Datenbank mystrongencryptdb.db, die mithilfe des Schlüssels gh67AB2 (starke Verschlüsselung) verschlüsselt ist:

CREATE DATABASE 'mystrongencryptdb.db' 
ENCRYPTED ON KEY 'gh67AB2';

Die folgende Anweisung erstellt die Datenbank mytableencryptdb.db mit aktivierter Tabellenverschlüsselung, die eine einfache Verschlüsselung verwendet. Beachten Sie das Schlüsselwort TABLE, das hinter ENCRYPTED eingefügt ist, um Tabellenverschlüsselung anstelle von Datenbankverschlüsselung anzugeben:

CREATE DATABASE 'mytableencryptdb.db' 
ENCRYPTED TABLE ON;

Die folgende Anweisung erstellt die Datenbank mystrongencrypttabledb.db mit aktivierter Tabellenverschlüsselung, die den Schlüssel gh67AB2 (starke Verschlüsselung) und den Verschlüsselungsalgorithmus AES_FIPS verwendet:

CREATE DATABASE 'mystrongencrypttabledb.db' 
ENCRYPTED TABLE ON KEY 'gh67AB2' 
ALGORITHM 'AES_FIPS';

Die folgende Anweisung erstellt eine Datenbankdatei mit dem Namen mydb.db, die die Kollatierung 1252LATIN1 verwendet. Die NCHAR-Kollatierung ist auf UCA gesetzt, wobei die Sprachumgebung auf "es" gesetzt und die Berücksichtigung der Groß-/Kleinschreibung und der Akzente aktiviert ist:

CREATE DATABASE 'my2.db' 
      COLLATION '1252LATIN1(case=respect)' 
      NCHAR COLLATION 'UCA(locale=es;case=respect;accent=respect)';