Ä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 Rechner überschritten hat. Weitere Hinweise finden Sie unter 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. Weitere Hinweise finden Sie unter 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. Weitere Hinweise finden Sie unter 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. Weitere Hinweise finden Sie unter 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. Weitere Hinweise finden Sie unter sa_conn_info-Systemprozedur.

Um diese Funktion zu verwenden, müssen Sie ein Upgrade Ihrer Datenbank ausführen. Weitere Hinweise finden Sie unter Upgrade von Datenbanken der Version 10 und höher.

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. Weitere Hinweise finden Sie unter 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). Weitere Hinweise finden Sie unter default_timestamp_increment-Option [Datenbank] [MobiLink-Client].

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 MByte auf 8 MByte erhöht. Weitere Hinweise finden Sie unter Serveroption -c.

Verhaltensänderungen durch clientseitiges Zwischenspeichern von Anweisungen im Cache   Die folgenden Verhaltensänderungen wurden im Zusammenhang mit der Unterstützung für das clientseitige Zwischenspeichern von Anweisungen im Cache 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. Weitere Hinweise finden Sie unter CREATE SERVICE-Anweisung.

Änderung des Standardwerts von SACommand.UpdateRowSource   Bislang war der Standardwert von SACommand.UpdatedRowSource der Wert UpdatedRowSource.Both. Nun lautet der Standardwert UpdatedRowSource.OutputParameters. Weitere Hinweise finden Sie unter UpdatedRowSource-Eigenschaft.

Ä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. Weitere Hinweise finden Sie unter PrefetchRows-Verbindungsparameter [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 Installationsverzeichnis\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 Installationsverzeichnis\scripts\authenticate.sql zu speichern. Weitere Hinweise finden Sie unter 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. Weitere Hinweise finden Sie unter 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 Option string_rtruncation 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. Weitere Hinweise finden Sie unter 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 Hostvariable als SQL_C_WCHAR verwendet wurden. In SQL Anywhere 10.0.0 werden Variable, 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. Weitere Hinweise finden Sie unter 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 später 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 ausführen
• connection_authentication-Option [Datenbank]
• database_authentication-Option [Datenbank]

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 in 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. Weitere Hinweise finden Sie unter 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) ist veraltet und wurde 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, ist nun veraltet und wird nicht mehr weiterentwickelt. Verwenden Sie stattdessen die Option -ea (d.h. "-ea simple"), um die einfache Verschlüsselung festzulegen. Weitere Hinweise finden Sie unter 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 veraltet   Aufgrund der Unterstützung der Kollatierungsanpassungen mithilfe von COLLATION und NCHAR COLLATION der CREATE DATABASE-Anweisung sind die Klauseln CASE und ACCENT dieser Anweisung nun veraltet. Weitere Hinweise finden Sie unter CREATE DATABASE-Anweisung.