CREATE DATABASE   Die Dateinamen (db-filename-string, log-filename-string und mirror-filename-string) sind Zeichenfolgen, die Betriebssystem-Dateinamen enthalten. Als Literal-Zeichenfolgen müssen sie von Apostrophen umschlossen sein.

Sie können nicht utility_db als db-filename-string eingeben. Dieser Name ist für die Dienstprogrammdatenbank reserviert.

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 der Kollationsanpassung 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 Kollation 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-Kollation erstellt wurden, wird die Berücksichtigung von Akzenten standardmäßig auf Sensitiv eingestellt.

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 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 Kollation.

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.

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 der Kollationsanpassung 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 Kollationen 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-Kollation 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.

CHECKSUM-Klausel   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 und ein Fehler tritt auf. Datenbanken, die mit aktivierten globalen Prüfsummen erstellt wurden, können auch mithilfe von Prüfsummen validiert werden. Sie können überprüfen, ob eine Datenbank mit aktivierten globalen Prüfsummen erstellt wurde, indem Sie die folgende Anweisung ausführen:

SELECT DB_PROPERTY ( 'Checksum' );

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

Ungeachtet der Einstellung dieser Klausel aktiviert der Datenbankserver das Schreiben von 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. Außerdem berechnet der Datenbankserver während der Validierung Prüfsummen für entscheidende Seiten.

Bei Datenbanken, für die keine globalen Prüfsummen aktiviert wurden, können Sie das Schreiben von Prüfsummen unter Verwendung der Optionen für -wc aktivieren.

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

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

Es ist wichtig, dass Sie Ihre Kollation mit Umsicht auswählen. Sie kann nicht mehr geändert werden, nachdem die Datenbank erstellt wurde.

Optional können Sie Optionen der Kollationsanpassung (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 Kollationsnamen angegeben. Beispiel: ... CHAR COLLATION 'UCA(locale=es;case=respect;accent=respect)'.

DATABASE SIZE-Klausel   Verwenden Sie diese optionale Klausel, um die Anfangsgröße der Datenbankdatei festzulegen. Verwenden Sie KB, MB, GB oder PAGES, um die Einheit in kB, MB, GB bzw. Seiten anzugeben.

Das Angeben der Dateigröße zum Zeitpunkt der Erstellung ist eine Möglichkeit, Speicherplatz für die Datei vorab zuzuweisen. Dies 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.

Klauseln DBA USER und DBA PASSWORD   Verwenden Sie diese Klauseln, um eine DBA-Benutzer-ID und ein DBA-Kennwort für die Datenbank anzugeben. Wenn Sie diese Klauseln nicht angeben, werden Sie zum Zeitpunkt der Erstellung aufgefordert, die DBA-Benutzer-ID und das DBA-Kennwort anzugeben.

ENCODING-Klausel   Die meisten in der COLLATION-Klausel angegebenen Kollationen legen sowohl die Kodierung (Zeichensatz) als auch die Sortierreihenfolge fest. Bei diesen Kollationen 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-Kollation auswählen, können Sie Optionen der Kollationsanpassung festlegen.

Wenn COLLATION auf UCA eingestellt ist und ENCODING nicht angegeben wurde, verwendet SQL Anywhere UTF-8.

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.

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. Ein Schlüssel kann entweder als Zeichenfolge oder als Variablenname angegeben werden.

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

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

JCONNECT-Klausel   Um dem jConnect JDBC-Treiber den Zugriff auf Systemkataloginformationen zu ermöglichen, geben Sie JCONNECT ON an. Diese Klausel installiert die Systemobjekte, die jConnect-Unterstützung zur Verfügung stellen. Geben Sie JCONNECT OFF an, 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.

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.

Beispiel:

CREATE DATABASE 'c:\\temp\\my_db.db' 
DBA USER 'DBA' DBA PASSWORD 'sql'
PAGE SIZE 4096;

NCHAR COLLATION-Klausel   Die durch die NCHAR COLLATION-Klausel angegebene Kollation wird für die Sortierung und den Vergleich von nationalen Zeichendatentypen verwendet (NCHAR, NVARCHAR und LONG NVARCHAR). Die Kollation 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 Kollation ist UTF8BIN, die eine binäre Sortierreihenfolge für alle Zeichen erstellt, deren Kodierung größer als 0x7E ist.

Optional können Sie Optionen der Kollationsanpassung (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 Anführungszeichen gesetzt werden, hinter dem Kollationsnamen angegeben. Zum Beispiel: ... NCHAR COLLATION 'UCA(locale=es;case=respect;accent=respect)'. Wenn Sie die ACCENT- oder die CASE-Klausel und eine Zeichenfolge zur Kollationsanpassung 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.

Klausel SYSTEM PROCEDURE AS DEFINER {ON | OFF}   Die SYSTEM PROCEDURE AS DEFINER-Klausel gibt an, ob Systemprozeduren vor Version 16.0, die mit Privilegien verbundene Aufgaben ausführen, mit den Privilegien des Aufrufers oder des Definierers (Eigentümers) ausgeführt werden sollen. ON bedeutet, dass diese Systemprozeduren mit den Privilegien des Definierers (Eigentümers) ausgeführt werden. OFF bedeutet, dass diese Systemprozeduren mit den Privilegien des Aufrufers ausgeführt werden.

Wenn diese Klausel nicht angegeben wird, werden diese Prozeduren standardmäßig mit den Privilegien des Aufrufers ausgeführt.

Diese Einstellung betrifft nicht benutzerdefinierte Prozeduren oder Systemprozeduren, die in Version 16.0 oder später eingeführt wurden. Hinweise dazu, welche Systemprozeduren betroffen sind und welche Auswirkungen die Einstellung hat, finden Sie unter Systemprozeduren vor Version 16.0 als Aufrufer oder Definierer ausführen.

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.

Mithilfe der MIRROR-Klausel der TRANSACTION-Klausel können Sie einen Dateinamen angeben, wenn Sie einen Transaktionslog-Spiegel verwenden. 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.