Prüfsummen sind standardmäßig für neue Datenbanken aktiviert   Wenn Sie eine neue Datenbank erstellen, werden globale Prüfsummen nun standardmäßig aktiviert. Globale Prüfsummen werden jedes Mal berechnet und überprüft, wenn eine Datenbankseite gelesen oder geschrieben wird. Sie werden verwendet, um zu bestimmen, ob eine Datenbankseite auf der Festplatte verändert wurde. Sie können mit der Option -s[ + | - ] des Initialisierungs-Dienstprogramms oder mit der CHECKSUM-Klausel der CREATE DATABASE-Anweisung kontrollieren, ob globale Prüfsummen für eine Datenbank aktiviert wurden. Weitere Hinweise finden Sie unter:

• Prüfsummenerweiterungen
• Dienstprogramm Initialisierung (dbinit)
• CREATE DATABASE-Anweisung
• START DATABASE-Anweisung

Änderungen des Checkpoint-Logs   In früheren Versionen hat SQL Anywhere das Checkpoint-Log vollständig gekürzt, wenn Sie eine Datenbank gestoppt haben. In Version 12 wird eine Verlaufsliste der Checkpoint-Log-Verwendung in der Datenbank verwaltet. Sie wird dazu verwendet, um eine passende Größe für das Checkpoint-Log für die nächste Sitzung zu ermitteln.

Durch die Verwaltung des Checkpoint-Logs über Sitzungen hinweg wird der Overhead für die Zuweisung beim jeweils nächsten Start der Datenbank ebenso vermieden wie die Dateifragmentierung, die auftreten kann, wenn Dateien erweitert werden. Datenbankdateien sind nun größer als in früheren Versionen, wenn die Datenbank heruntergefahren wird, aber der zusätzliche Speicherplatz wird für das Checkpoint-Log wieder verwendet, wenn die Datenbank das nächste Mal neu gestartet wird. Siehe Hinweise zum Checkpoint-Log.

Netzwerk-Datenbankserver weist nun die maximale Anzahl von Worker-Threads zu   In früheren Versionen wurde beim Start des Netzwerk-Datenbankservers die Anzahl von Worker-Threads zugewiesen, die der Multiprogramming-Stufe des Datenbankservers entsprechen. In Netzwerkservern der Version 12 entspricht die Anzahl von zugewiesenen Worker-Threads der maximalen Multiprogramming-Stufe des Servers. Diese Zunahme der Anzahl von Worker-Threads erhöht die Anforderungen an den Adressraum des Netzwerk-Datenbankservers für Worker-Stacks. Außerdem kann sie Auswirkungen auf den Umfang des Datenbankcaches haben, den der Datenbankserver zuweisen kann.

Auf 32-Bit-Windows-Plattformen erfordert jeder Worker-Thread z.B. 1 MByte Adressraum für seinen Stack. Ein Netzwerkserver der Version 11, der unter Windows startet, würde 20 MByte Adressraum für Worker-Stacks erfordern, da seine standardmäßige Multiprogramming-Stufe 20 ist. Ein Netzwerkserver der Version 12, der unter Windows startet, erfordert 80 MByte Adressraum, da die standardmäßige maximale Anzahl von Worker-Threads 80 ist. Diese Änderung hat keine Auswirkungen auf Personal Server oder Windows Mobile. Siehe Threads in SQL Anywhere.

Alte Statistiken werden nicht geladen, wenn eine Datenbank neu aufgebaut wird   Beim Neuaufbau einer Datenbank der Version 11 oder früher überspringt die LOAD STATISTICS-Anweisung stillschweigend das Laden von alten Zeichenfolgenstatistiken in die neue Datenbank, führt aber ein Upgrade der Version der Zeichenfolgenstatistiken durch. Siehe LOAD STATISTICS-Anweisung.

Beim Upgrade einer Datenbank (mit dem Upgrade-Dienstprogramm) wird kein Upgrade der Version der Zeichenfolgenstatistiken vorgenommen.

Positionierte DELETE- und UPDATE-Anweisungen   In früheren Versionen konnten Sie eine TOP- oder FIRST-Klausel für eine positionierte UPDATE- oder DELETE-Anweisung angeben. Die Klauseln wurden jedoch ignoriert. Jetzt gibt die Angabe von TOP oder FIRST in einer positionierten UPDATE- oder DELETE-Anweisung einen Syntaxfehler zurück. Siehe UPDATE-Anweisung (positionsbasiert) [ESQL] [SP] und DELETE-Anweisung (positionsbasiert) [ESQL] [SP].

JDBC-Treiber geben jetzt CHAR und VARCHAR anstelle von nur CHAR für beiden Typen zurück   Wenn eine Anwendung in früheren Versionen eine Verbindung unter Verwendung des iAnywhere JDBC-Treibers hergestellt hat und versucht hat, die Metadaten einer Tabelle oder Ergebnismenge mit einer CHAR-Spalte zu beschreiben, gaben die Metadaten als Spaltentyp CHAR zurück. Der SQL-Typ wurde jedoch als Types.VARCHAR zurückgegeben. Wenn in einer JDBC-Anwendung der JDBC-Treiber den SQL-Typ von CHAR-Spalten als Types.CHAR zurückgeben sollte, musste die Anwendung die odbc_distinguish_char_and_varchar-Datenbankoption festlegen. Nun geben der neue SQL Anywhere JDBC-Treiber und der nicht mehr empfohlene iAnywhere JDBC-Treiber den Typnamen CHAR und den SQL-Typ Types.CHAR für Tabellen- und Ergebnismengenspalten des Typs CHAR zurück sowie den Typnamen VARCHAR und den SQL-Typ Types.VARCHAR für Spalten vom Typ VARCHAR, und zwar unabhängig von der Einstellung der Datenbankoption.

Änderungen von CURRENT UTC TIMESTAMP- und UTC TIMESTAMP-Spezialwerte   Der zu Grunde liegende Datentyp für den CURRENT UTC TIMESTAMP-Spezialwert und der Standardwert für den UTC TIMESTAMP-Spezialwert ist nun TIMESTAMP WITH TIME ZONE. Wenn diese Werte für Spalten verwendet werden, die als TIMESTAMP definiert sind, wird der Zeitzonen-Offset gekürzt und es sollte kein Unterschied im Verhalten erkennbar sein. Wenn diese Werte jedoch für CHAR- oder VARCHAR-Spalten verwendet werden, führt der Offset dazu, dass andere Werte als zuvor generiert werden. Siehe CURRENT UTC TIMESTAMP-Spezialwert und UTC TIMESTAMP-Spezialwert.

Personal Server startet TCP/IP nicht mehr standardmäßig   Der Personal Datenbankserver startet nur noch das Shared Memory-Protokoll standardmäßig. Wenn Sie das TCP/IP-Protokoll verwenden möchten, müssen Sie dies beim Start des Personal Datenbankservers mithilfe der Serveroption -x angeben. Siehe -x - dbeng12/dbsrv12-Serveroption und Kommunikationsprotokolle auswählen.

TCP/IP-Verbindungen   Wenn Sie eine Verbindung über TCP/IP herstellen, ist der Datenbankservername (durch den Verbindungsparameter ServerName (SERVER) festgelegt) nicht mehr erforderlich, sofern mit dem Verbindungsparameter HOST ein Hostname angegeben wird. Siehe Verbindungsparameter Host.

Host-Protokolloption (IP)   In früheren Versionen gab die Host-Protokolloption nicht nur einen oder mehrere Hosts an, auf dem bzw. auf denen der Datenbankserver lief, sondern sie diente auch als Hint für die Clientbibliothek. Konnte der Datenbankserver auf den angegebenen Hosts nicht gefunden werden, wurde ein Netzwerk-Broadcast zur Suche des Datenbankservers durchgeführt. Wenn Sie nun die Host-Option angeben, werden nur die festgelegten Hosts nach dem Datenbankserver durchsucht, und der Client führt standardmäßig keinen Broadcast durch.

Dieses Verhalten ist vergleichbar mit der Einstellung 'Direkt' für die DoBroadcast-Protokolloption. Wenn der Datenbankserver auf einem anderen Computer als von der HOST-Protokolloption angegeben läuft, wird er nicht gefunden. Wenn Sie das Verhalten aus früheren Versionen vorziehen, legen Sie in der Verbindungszeichenfolge DoBroadcast=All fest. Siehe Host-Protokolloption (IP) und DoBroadcast-Protokolloption (DOBROAD).

ServerPort [PORT]-Protokolloption   In früheren Versionen legte die PORT-Protokolloption nicht nur eine oder mehrere Nummern der Ports fest, an denen der Datenbankserver auf eine Anfrage warten sollte, sondern sie diente auch als Hint für die Clientbibliothek. Beim Senden eines Broadcasts durch die Clientbibliothek wurden die mit der PORT-Protokolloption angegebenen Portnummern verwendet, sowie die Standardportnummer 2638. Wenn Sie nun die PORT-Option angeben, werden nur die festgelegten Ports bei der Suche nach dem Datenbankserver verwendet. Siehe ServerPort-Protokolloption (PORT).

Unterstützung des Idle-Verbindungsparameters für Shared Memory   Der Idle-Verbindungsparameter legt die Dauer für die Zeitüberschreitung bei inaktiver Verbindung fest. Dieser Parameter wird nun bei Verbindungen mit Shared Memory berücksichtigt. Der Standardwert für die Zeitüberschreitung bei Inaktivität bei Shared Memory-Verbindungen ist Null (keine Zeitüberschreitung bei Inaktivität). Siehe Verbindungsparameter Idle.

Der Datenbankservername kann sich vom Namen im Verbindungsparameter ServerName (Server) unterscheiden   In früheren Versionen stimmte der Wert der Datenbankeigenschaft Name immer mit dem des Verbindungsparameters ServerName (Server) überein. Wenn ein Client eine Verbindung mit einer Datenbank herstellt, den neuen Verbindungsparameter NodeType (NODE) verwendet und zu einem anderen Datenbankserver umgeleitet wird, stimmen die Namen jedoch nicht überein. Siehe Verbindungsparameter NodeType (NODE).

Manche Vorgänge werden bei der Verbindung mit alternativem Servernamen nicht unterstützt   Wenn in früheren Versionen ein Client eine Datenbankverbindung unter Verwendung eines alternativen Servernamens herstellte, konnten andere Datenbanken auf demselben Datenbankserver erstellt, gestoppt und gelöscht werden. Diese Vorgänge werden nun nicht mehr unterstützt, wenn Sie eine Verbindung mithilfe eines alternativen Servernamens herstellen.

Verhaltensänderungen der Datenbankspiegelung und veraltete Funktionen   Bei der Serveroption -xp zum Festlegen von Datenbankspiegelungsoptionen werden Optionen wie der Name des Arbiterservers, die Authentifizierungszeichenfolge und der Synchronisationsmodus nun nicht mehr empfohlen. Wenn Sie den Datenbankserver in einem Spiegelsystem verwenden möchten, müssen jedoch nach wie vor -xp on angeben. Siehe -xp - dbsrv12-Datenbankoption.

Sie können die Datenbankspiegelungsoptionen nun mithilfe der folgenden SQL-Anweisungen festlegen:

• CREATE MIRROR SERVER-Anweisung
• ALTER MIRROR SERVER-Anweisung
• SET MIRROR OPTION-Anweisung

Die neue Version umfasst die folgenden Verhaltensänderungen bei Datenbankspiegelungen:

• In früheren Versionen wurde die Statusinformationsdatei für einen Spiegelserver standardmäßig nach dem Servernamen benannt. Nun müssen Sie den Namen der Statusinformationsdatei explizit angeben.
• In früheren Versionen wurden Webdienste-Anforderungen, die an den Spiegelserver gerichtet waren, zum Primärserver umgeleitet. In dieser Version werden diese Anforderungen direkt von dem Server verarbeitet, an den sich gerichtet sind.

Weitere Hinweise zu den Erweiterungen der Datenbankspiegelung in dieser Version finden Sie unter Erweiterungen der Datenbankspiegelung.

Verhaltensänderung des Embedded SQL-Cursors   Embedded SQL-Cursor werden nun standardmäßig auf READ ONLY gesetzt. Explizite FOR READ ONLY- oder FOR UPDATE-Klauseln müssen nun in der PREPARE-Anweisung anstatt in der DECLARE-Anweisung angegeben werden. Weitere Hinweise finden Sie unter:

• DECLARE CURSOR-Anweisung [ESQL] [SP]
• PREPARE-Anweisung [ESQL]

Geschlossene Cursor für CREATE OR REPLACE PROCEDURE-Anweisungen   Wenn Sie eine CREATE OR REPLACE PROCEDURE-Anweisung ausführen, werden alle für eine Verbindung geöffneten Cursor geschlossen. Siehe CREATE PROCEDURE-Anweisung.

Back Quotes als Begrenzer für Bezeichner   Back Quotes (`) können jetzt als Begrenzer für Bezeichner verwendet werden. Siehe Bezeichner.

Verändertes Sperrverhalten   Um die Parallelität zu optimieren, können nun die Zeilenbereiche mit und ohne Schlüssel separat gesperrt werden. Nicht-Schlüsselspalten einer Zeile lassen sich aktualisieren, ohne dass das Einfügen und Löschen von Fremdzeilen, die auf diese Zeile verweisen, beeinträchtigt wird. Siehe Funktionsweise von Sperren.

Verhaltensänderung des ODBC-Treibers   Die ODBC-Funktion SQLTables ermöglicht es Ihnen, über das Argument SQL_ALL_SCHEMAS eine Liste aller Schemata (Benutzer) abzurufen. In früheren Versionen umfasste diese Liste nur Benutzer, die Eigentümer einer Tabelle sind. In einer neu initialisierten Datenbank wurden dadurch einige Benutzer ausgeschlossen, insbesondere DBA-Benutzer. Nun wird die vollständige Schemataliste zurückgegeben, einschließlich der Benutzer, die nicht Eigentümer einer Tabelle sind.

divide_by_zero_error-Option   Die Option divide_by_zero_error wurde in Version 11 nicht unterstützt. In Version 12 kann sie nun verwendet werden. Wenn Sie materialisierte Ansichten verwenden, müssen Sie diese Option aktivieren (Standardeinstellung), um neue materialisierte Ansichten erstellen zu können. Siehe divide_by_zero_error-Option und Einschränkungen bei materialisierten Ansichten.

PrefetchBuffer-Verbindungsparameter (PBUF)   In früheren Versionen wurde das mit dem Verbindungsparameter PrefetchBuffer (PBUF) festgelegte Speichervolumen für die Zeilenpufferung für alle Verbindungen verwendet. In dieser Version steht das mit diesem Parameter angegebene Speichervolumen für jede einzelne Verbindung zur Verfügung. Siehe Verbindungsparameter PrefetchBuffer (PBUF).

Automatisches Löschen externer Logins für gelöschte Benutzer   Wenn Sie einen Benutzer aus der Datenbank entfernen, werden nun auch automatisch alle externen Logins für diesen Benutzer gelöscht. In früheren Versionen mussten Sie die externen Logins separat löschen. Siehe Benutzer aus der Datenbank entfernen.

Der Datenbankaufräumvorgang und die Datenbankvalidierung können nicht mehr gleichzeitig durchgeführt werden.   In früheren Versionen konnten der Datenbankaufräumvorgang und die Datenbankvalidierung gleichzeitig durchgeführt werden. Bei gleichzeitigem Zugriff auf Datenbankseiten wurden Fehler ausgegeben. In der neuen Version lassen sich diese beiden Vorgänge nicht mehr gleichzeitig für dieselbe Datenbank durchführen. Die Validierung erfolgt erst nach dem Datenbankaufräumvorgang, und der Datenbankaufräumvorgang erfolgt erst nach der Validierung, wenn der Aufräumvorgang durch den Aufruf von sa_clean_database gestartet wurde. Der Datenbankaufräumvorgang kann gleichzeitig mit Tabellen- oder Indexvalidierungen durchgeführt werden.

Geänderte Datentypen für Spalten in der Systemprozedur sa_index_density   Der Datentyp der Dichte- und Überhangspalten wurde von numeric(8,6) in double geändert. Siehe sa_index_density-Systemprozedur.

DATEDIFF-Funktion   In früheren Versionen gab die DATEDIFF-Funktion einen INTEGER-Wert für Stunden oder kleinere Einheiten von Datumsteilen zurück. Nun gibt DATEDIFF einen BIGINT-Wert für diese Datumsteile zurück. Siehe DATEDIFF-Funktion [Datum und Uhrzeit].

openxml-Systemprozedur   In früheren Versionen konvertierte die openxml-Systemprozedur NCHAR-Daten in den CHAR-Zeichensatz und führte eine syntaktische Analyse der Daten im CHAR-Format durch. Nun werden NCHAR-Daten im NCHAR-Zeichensatz analysiert, wenn NCHAR-Spalten in der Ausgabe enthalten sind.

In früheren Versionen konnten die XPath-Argumente in der WITH-Klausel nur Literalzeichenfolgen sein. Nun sind Literalzeichenfolgen und Variable erlaubt. Siehe openxml-Systemprozedur.

sa_text_index_vocab-Systemprozedur   Der Versuch, sa_text_index_vocab für einen NCHAR-Textindex aufzurufen, gibt nun einen Fehler zurück. Verwenden Sie stattdessen die neue sa_text_index_vocab_nchar-Systemprozedur. Siehe sa_text_index_vocab_nchar-Systemprozedur.

Außerdem:

Geänderte Standardkollatierung für Mac OS X   Wenn in früheren Versionen keine Umgebungsvariablen für Mac OS X vorhanden waren, verwendete das Dienstprogramm Initialisierung (dbinit) als standardmäßigen CHAR-Zeichensatz ISO_8859-1:1987 und für die CHAR-Kollatierung ISO1LATIN1 (dasselbe Verhalten wie Linux). Nun wird UTF-8 mit der UTF8BIN-Kollatierung verwendet. Siehe Empfohlene Zeichensätze und Kollatierungen.

Reservierte Wörter   Im Folgenden finden Sie eine Liste der reservierten Wörter, die der Datenbank in SQL Anywhere Version 12.0.0 hinzugefügt wurden:

Im Folgenden finden Sie eine Liste der reservierten Wörter, die aus der Datenbank in SQL Anywhere Version 12.0.0 entfernt wurden: