Änderungen der Verwendung der abfrageinternen Parallelität   Die abfrageinterne Parallelität wird nicht mehr bei Verbindungen verwendet, für die background_priority aktiviert ist. Außerdem wird die abfrageinterne Parallelität nicht verwendet, wenn die Anzahl der Server-Threads, die aktuell eine Abfrage bearbeiten (Servereigenschaft ActiveReq), die laut Lizenz zulässige Anzahl der vom Datenbankserver verwendbaren CPU-Kerne auf dem Computer überschritten hat. Siehe Fortgeschrittene Aufgaben: Parallelität während der Abfrageausführung.

Die neue Servereigenschaft ExchangeTasksCompleted gibt die Gesamtanzahl von internen Aufgaben zurück, die seit dem Start der Datenbank für die abfrageinterne Parallelität verwendet wurden. Siehe Zugreifen auf Werte von Datenbankservereigenschaften.

Verschlüsselungsergebnisse sind nicht mehr deterministisch   Bislang war das Verschlüsseln von Werten mithilfe der Funktion ENCRYPT deterministisch. Wenn Sie zwei identische Eingabezeichenfolgen und zwei identische Chiffrierschlüssel eingegeben haben, wurden identische Ausgabedaten (Chiffrierungstext) zurückgegeben. Nun können Sie mit der neuen Datenbankoption encrypt_aes_random_iv steuern, ob die Verschlüsselung deterministisch ist. Das neue Standardverhalten ist nicht deterministisch.

ALTER DBSPACE RENAME versucht, den DBSpace zu öffnen, wenn er nicht geöffnet ist   Wenn bislang eine Datenbank, die DBSpaces verwendet, gestartet und einer ihrer DBSpaces nicht gefunden wurde, dann wurde der DBSpace-Name im Katalog durch die Ausführung der Anweisung ALTER DBSPACE...RENAME für den betreffenden DBSpace aktualisiert. Es wurde jedoch nicht versucht, den DBSpace zu starten. Nun versucht der Datenbankserver, den DBSpace zu öffnen, nachdem der Katalog aktualisiert wurde. Siehe ALTER DBSPACE-Anweisung.

Änderungen der Anweisungen CREATE, ALTER und DROP DBSPACE   Die Anweisungen CREATE DBSPACE und DROP DBSPACE akzeptieren nicht mehr die Namen von vordefinierten DBSpaces (SYSTEM, TEMPORARY, TEMP, TRANSLOG und TRANSLOGMIRROR). Wenn ein Benutzer-DBSpace in einer Datenbank, die von einer älteren Version des SQL Anywhere-Datenbankservers erstellt wurde, denselben Namen hat wie einer der vordefinierten DBSpaces, bezieht sich der Datenbankserver immer auf den Benutzer-DBSpace. Siehe Vordefinierte DBSpaces.

Änderungen der Ausgabe der Systemprozedur sa_conn_info   Die Ausgabe der Systemprozedur sa_conn_info wurde geändert und gibt nun mehr Informationen über Sperren zurück, auf die Verbindungen warten. Das Feld LockName wurde entfernt. An seiner Stelle wurden die zwei neuen Felder LockRowID und LockIndexID hinzugefügt. Wenn die Verbindung auf eine Sperre wartet, die einer bestimmten Zeilen-ID zugeordnet ist, enthält LockRowID diese Zeilen-ID. Wenn die Verbindung auf eine Sperre wartet, die einem bestimmten Index zugeordnet ist, enthält LockIndexID diese Index-ID. Siehe sa_conn_info-Systemprozedur.

Um diese Funktion zu verwenden, müssen Sie ein Upgrade Ihrer Datenbank ausführen. Siehe Upgradevorgang für Datenbanken der Version 10 und später.

DBA-Berechtigung für einige Systemprozeduren nicht mehr erforderlich   Für die Ausführung der Systemprozeduren sa_dependent_views, sa_get_dtt, sa_check_commit und sa_materialized_view_info ist die DBA-Berechtigung nicht mehr erforderlich.

Standardmaßeinheit für CREATE DATABASE-Anweisung wurde entfernt   Bei der Erstellung einer Datenbank mit der CREATE DATABASE-Anweisung ist die Angabe der Maßeinheit nicht mehr optional, wenn Sie einen Wert für DATABASE SIZE festlegen. Siehe CREATE DATABASE-Anweisung.

Neuer Höchstwert für die Option default_timestamp_increment   Der Höchstwert für die Option default_timestamp_increment ist nun 1000000 (1 Sekunde). Siehe default_timestamp_increment-Option.

dbdata10.dll entfernt   Die von der dynamischen Verknüpfungsbibliothek (Dynamic Link Library) dbdata10 bereitgestellte Funktionalität wurde in die DLL des SQL Anywhere .NET-Providers integriert. Aus diesem Grund gibt es nun für Windows CE plattformspezifische Versionen der DLL des SQL Anywhere .NET-Providers.

Erhöhte Standard-Cachegröße unter NetWare   Die Standardgröße des Datenbankserver-Caches unter NetWare wurde von 2 MB auf 8 MB erhöht. Siehe -c - dbeng12/dbsrv12-Serveroption.

Verhaltensänderungen durch clientseitiges Caching von Anweisungen   Die folgenden Verhaltensänderungen wurden im Zusammenhang mit der Unterstützung für das clientseitige Caching von Anweisungen eingeführt:

Das Sprachen-Dienstprogramm (dblang) erfordert keine Administratorberechtigungen mehr   In früheren Versionen von SQL Anywhere mussten sich Benutzer als Administrator anmelden, um die Spracheinstellungen für lokalisierte Versionen von SQL Anywhere mithilfe des Dienstprogramms dblang ändern zu können. Diese Anforderung wurde aufgehoben.

Schrägstriche in DISH-Dienstnamen nicht mehr zulässig   Um eine Fehlinterpretation von DISH-Dienstnamen zu verhindern, sind Schrägstriche (/) als Teil des Dienstnamens nicht mehr zulässig. Siehe CREATE SERVICE-Anweisung [SOAP-Webdienst].

Änderung des Standardwerts von SACommand.UpdateRowSource   Bislang war der Standardwert von SACommand.UpdatedRowSource der Wert UpdatedRowSource.Both. Nun lautet der Standardwert UpdatedRowSource.OutputParameters. Siehe SACommand.UpdatedRowSource-Eigenschaft [SQL Anywhere .NET].

Änderung des Standardwerts des PrefetchRows-Verbindungsparameters   Bei der Verwendung des .NET-Datenproviders wurde der Standardwert des Verbindungsparameters PrefetchRows zur Verbesserung der Performance von 10 auf 200 gesetzt. Der Standardwert von SAConnectionStringBuilder.PrefetchRow ist nun ebenfalls 200. Prefetch-Vorgänge sind nun deaktiviert, wenn die Ergebnismenge BLOB-Spalten enthält. Siehe Verbindungsparameter PrefetchRows (PROWS).

Authentifizierte Anwendungen verwenden nun authenticate.sql anstelle von saopts.sql   In früheren Versionen der OEM Edition von SQL Anywhere wurde empfohlen, die Authentifizierungsanweisung in der Datei %SQLANY10%\scripts\saopts.sql zu speichern, sodass sie immer angewendet wurde, wenn Sie eine Datenbank erstellt, neu aufgebaut oder ein Upgrade der Datenbank durchgeführt haben.

Nun wird empfohlen, die Authentifizierungszeichenfolge in der Datei %SQLANY10%\scripts\authenticate.sql zu speichern. Siehe Upgrade von authentifizierten Datenbanken.

Lange Hostnamen werden unter HP-UX nun akzeptiert   Seit dem Update vom September 2004 von HP-UX 11i v2 konnten Systemadministratoren die Unterstützung für 255-Byte-Hostnamen durch das Setzen eines Kernel-Parameters aktivieren. Auf SQL Anywher-Servern auf HP-UX-Computern, auf denen lange Hostnamen aktiviert waren, gaben die Eigenschaft MachineName und der HOST-Schlüssel AppInfo maximal 64 Byte des Hostnamens zurück. Sowohl MachineName als auch AppInfo können nun 255-Byte-Hostnamen zurückgeben.

URL-Header des iAnywhere JDBC-Treibers   Wenn in früheren Versionen Anwendungen unter Verwendung des iAnywhere JDBC-Treibers mit SQL Anywhere verbunden wurden, begann der URL, der an den JDBC-Treiber übergeben wurde, mit dem Header jdbc:odbc:. Nun kann der URL-Header auch mit jdbc:ianywhere: beginnen. Es wird emfpohlen, jdbc:ianywhere: zu verwenden, um Konflikte mit der JDBC-ODBC-Brücke von Sun zu vermeiden. Siehe Dem Treiber eine URL bereitstellen.

Abfragen einer Liste von Tabellen mit jConnect, wenn der Remarks-Wert länger als 128 Zeichen ist   Wenn bislang eine JDBC-Anwendung mithilfe von jConnect verbunden wurde und eine Liste von Tabellen angefordert hat, war das Ergebnis möglicherweise leer, auch wenn Tabellen vorhanden waren. Dies war der Fall, wenn die string_rtruncation-Option auf On gesetzt war, die Anwendung die Methode DatabaseMetaData.getTables verwendet hat und der Remarks-Wert für eine beliebige Tabelle länger als 128 Zeichen war. Nun werden zu lange Remarks-Werte auf 128 Zeichen gekürzt und die Liste der Tabellen wird zurückgegeben. Um diese Änderung nutzen zu können, müssen Sie entweder jcatalog.sql ausführen oder Ihre Datenbank auf die neue Version umstellen. Siehe jConnect-Systemobjekte in einer Datenbank installieren oder Upgrade-Dienstprogramm (dbupgrad).

Vergleiche von CHAR- und NCHAR-Werten   Bei SQL Anywhere 10.0.0 führte die Kombination von CHAR- und NCHAR-Domänen zu einem NCHAR-Vergleich. Dies bedeutete jedoch, dass Anwendungen, die auf 10.0.0 umgestellt wurden, unter Umständen unterschiedliche Ergebnisse erzielten oder einen Performanceabfall verzeichneten, wenn gebundene Hostvariablen als SQL_C_WCHAR verwendet wurden. In SQL Anywhere 10.0.0 werden Variablen, die als SQL_C_WCHAR gebunden sind, als NCHAR dargestellt. In SQL Anywhere 10.0.1 wurden neue Inferenzregeln eingeführt, um die Kompatibilität mit vorhandenen Anwendungen zu verbessern und konsistente, vorhersehbare Ergebnisse zu liefern, wenn CHAR- und NCHAR-Domänen kombiniert werden. Siehe Vergleiche zwischen CHAR und NCHAR.

Asynchrone I/O-Vorgänge auf früheren Linux-Kernels als 2.6.12 deaktiviert   Aufgrund eines Fehlers in Linux-Kernels vor Version 2.6.12 sind asynchrone I/O-Vorgänge standardmäßig deaktiviert, wenn Sie einen SQL Anywhere-Datenbankserver auf einem der betreffenden Kernels ausführen. Wenn Sie asynchrone I/O-Vorgänge verwenden möchten, müssen Sie Ihren Kernel auf 2.6.12 oder höher umstellen.

Dokumentation der OEM Edition verschoben   In früheren Versionen der OEM Edition von SQL Anywhere waren Anleitungen zum Einrichten von authentifizierten Anwendungen in einer separaten .pdf- oder .html-Datei enthalten. Diese Informationen sind jetzt auch an folgenden Stellen verfügbar:

• Authentifizierte SQL Anywhere-Anwendungen
• connection_authentication-Option
• database_authentication-Option

Tabellennamen müssen die Groß- und Kleinschreibung nicht mehr berücksichtigen, wenn die Optionen -e und -t des Dienstprogramms Entladen für eine Datenbank verwendet werden, die die Groß- und Kleinschreibung berücksichtigt   In früheren Versionen mussten die Tabellennamen die Groß- und Kleinschreibung berücksichtigen, wenn die Optionen -e und -t des dbunload-Dienstprogramms zum Entladen einer Datenbank, die die Groß- und Kleinschreibung berücksichtigt, verwendet wurden. Die Tabellennamen müssen nun die Groß- und Kleinschreibung nicht mehr berücksichtigen.

Daten in temporäre Tabellen laden   Das Verhalten beim Laden von Daten in temporäre Tabellen wurde geändert. Abgesehen von einer mit ON COMMIT DELETE ROWS definierten LOCAL TEMPORARY TABLE-Tabelle wird nun eine temporäre Tabelle vor und nach einer LOAD TABLE-Anweisung automatisch festgeschrieben. Wenn der Ladevorgang fehlschlägt, werden nun alle Zeilen aus der temporären Tabelle entfernt, einschließlich der Zeilen, die vor dem Ladevorgang enthalten waren.

Bei LOCAL TEMPORARY TABLE-Tabellen, die mit ON COMMIT DELETE ROWS definiert wurden, gibt es keine Verhaltensänderung, d.h. es werden keine Festschreibungen durchgeführt. Wenn ein Ladevorgang aufgrund eines Fehlers nur teilweise ausgeführt wird, enthält dieser temporäre Tabellentyp nur einige der geladenen Zeilen, während andere Zeilen, die vor dem Ladevorgang enthalten waren, möglicherweise fehlen.

Außerdem schlägt das Laden in eine temporäre Tabelle nun fehl, wenn die Tabelle Zeilen enthält, die vom Fremdschlüssel einer anderen Tabelle referenziert werden.

Es ist nicht möglich, einen Ladevorgang in eine globale temporäre Tabelle (GLOBAL TEMPORARY TABLE) durchzuführen, für die ON COMMIT DELETE ROWS festgelegt ist.

Standardmäßige Berücksichtigung von Groß- und Kleinschreibung in japanischen Datenbanken, die die UCA-Kollatierung verwenden   Standardmäßig werden die Groß- und Kleinschreibung und die Akzente der UCA-Kollatierungen bei der Erstellung japanischer Datenbanken nun berücksichtigt. Eine japanische Datenbank ist eine Datenbank, die auf einem japanischen Computer erstellt wird, auf dem die Betriebssystemsprache Japanisch ist, ein japanischer Zeichensatz verwendet wird oder eine beliebige Datenbank, die mit einer japanischen CHAR-Kollatierung wie z.B. 932JPN oder EUC_JAPAN erstellt wird.

Standardmäßig wird die Groß- und Kleinschreibung der UCA-Kollatierungen bei der Erstellung nicht-japanischer Datenbanken weiterhin nicht berücksichtigt.

Die Standardeinstellungen für die Berücksichtigung von Groß- und Kleinschreibung und Akzenten können weiterhin mit den dbinit-Optionen -c und -a (oder -c- und -a-) überschrieben werden, und zwar mithilfe einer Kollatierungsanpassungssyntax oder der Klauseln CASE und ACCENT der CREATE DATABASE-Anweisung. Siehe Dienstprogramm Initialisierung (dbinit) und CREATE DATABASE-Anweisung.

SQL Flagger-Unterstützung für den SQL/1992-Standard   Die SQL Flagger-Unterstützung für SQL:1992 (alle Ebenen) wird nicht mehr empfohlen und nicht mehr weiterentwickelt.

dbinit-Option -e wird nicht weiterentwickelt   Die Option -e von dbinit, mit der bei der Datenbankerstellung die einfache Verschlüsselung festgelegt wurde, wird nun nicht mehr empfohlen und nicht mehr weiterentwickelt. Verwenden Sie stattdessen die Option -ea (d.h. "-ea simple"), um die einfache Verschlüsselung festzulegen. Siehe Dienstprogramm Initialisierung (dbinit).

SADbType.oldbit-Datentyp wurde entfernt   Die SADbType.oldbit-Enumerationskonstante wurde aus dem SQL Anywhere .NET-Provider entfernt.

-gx-Serveroption wird nicht weiterentwickelt   Auf Windows-PC-Plattformen versucht der Datenbankserver-Scheduler nun, die Affinität von Anforderungen zu verwalten, um den CPU-Cache zu verwenden. Dadurch werden Anforderungen soweit möglich auf einer CPU ausgeführt. Zudem wird die Serveroption -gx, mit der die Anzahl der Betriebssystem-Threads für den Datenbankserver festgelegt wurde, nicht weiterentwickelt. Diese Option wird nun vom Datenbankserver ignoriert.

CASE- und ACCENT-Klauseln der CREATE DATABASE-Anweisung nicht mehr empfohlen   Aufgrund der Unterstützung der Kollatierungsanpassungen mithilfe von COLLATION und NCHAR COLLATION der CREATE DATABASE-Anweisung werden die Klauseln CASE und ACCENT dieser Anweisung nun nicht mehr empfohlen. Siehe CREATE DATABASE-Anweisung.