Standardsicherheitsmodell für einige Systemprozeduren wurde geändert   Einige Systemprozeduren vor Version 16.0 führen Vorgänge in der Datenbank durch, die Berechtigungen erfordern. Im Sicherheitsmodell vor Version 16.0 wurden diese Prozeduren mit den Berechtigungen des Definierers (Eigentümer) ausgeführt, sodass der Benutzer nur die Berechtigung zum Ausführen der Prozedur selbst benötigte und nicht die Berechtigungen für alle von der Prozedur durchgeführten Vorgänge. In einigen Ausnahmefällen war außerdem die DBA-Berechtigung erforderlich.

Ab Version 16.0 ändert sich das Standard-Sicherheitsmodell für diese Prozeduren. Standardmäßig werden diese Prozeduren in neu erstellten Datenbanken mit den Privilegien des aufrufenden Benutzers ausgeführt. Um eine Prozedur ausführen zu können, muss der Aufrufer daher die in der Dokumentation für die Prozedur angegebenen Privilegien haben. Der Aufrufer benötigt außerdem das EXECUTE-Privileg für die Prozedur, das er jedoch als Mitglied von PUBLIC erbt.

Sie können bei der Erstellung der Datenbank steuern, ob das alte Modell oder das neue Modell verwendet wird, indem Sie die neue SYSTEM PROCEDURE AS DEFINER-Klausel der CREATE DATABASE-Anweisung oder die Option -pd des Dienstprogramms Initialisierung (dbinit) angeben. Manche Systemprozeduren erfordern jedoch immer die in der Dokumentation angegebenen Privilegien, unabhängig von der Einstellung für das Sicherheitsmodell. Eine Liste dieser Prozeduren finden Sie unter Systemprozeduren vor Version 16.0 als Aufrufer oder Definierer ausführen.

Beim Upgrade einer Datenbank besteht das Standardverhalten darin, das bereits eingerichtete Sicherheitsmodell beizubehalten. Das heißt beispielsweise, dass beim Upgrade einer Datenbank der Version 12.0.1 die Datenbank nach dem Upgrade weiterhin das alte Sicherheitsmodell verwendet, sofern Sie nichts anderes angeben.

Wenn Sie zum Zeitpunkt des Upgrades steuern möchten, welches Sicherheitsmodell verwendet wird, können Sie die SYSTEM PROCEDURE AS DEFINER-Klausel der ALTER DATABASE-Anweisung oder die Option -pd des Dienstprogramms zum Upgrade (dbupgrad) verwenden. Dieselben Ausnahmen bezüglich der Systemprozeduren, die immer sowohl EXECUTE als auch spezifische Privilegien erfordern, gelten für Upgrade wie Erstellung.

• Änderungen für Systemprozeduren, die mit Privilegien verbundene Vorgänge ausführen
• Systemprozeduren vor Version 16.0 als Aufrufer oder Definierer ausführen
• Liste der Prozeduren, die durch die Aufrufer/Definierer-Einstellung beeinflusst werden
• ALTER DATABASE-Anweisung
• CREATE DATABASE-Anweisung
• Dienstprogramm Initialisierung (dbinit)
• Dienstprogramm zum Upgrade (dbupgrad)

Relative Pfade und Sandboxing   In früheren Versionen war der Standardwert für relative Pfade immer das Arbeitsverzeichnis des Datenbankservers. Wenn Sandboxing für eine Datenbank aktiviert ist, sind relative Pfade nur relativ zum Verzeichnis der Datenbank und nicht zum Verzeichnis des Datenbankservers. Siehe Sandboxing.

SELECT * wird in Ansichtsdefinitionen unterstützt   In früheren Versionen wurde SELECT * nur in der Hauptabfrage der CREATE VIEW-Anweisung unterstützt. Nun wird es in der Hauptabfrage unterstützt sowie in einer Unterabfrage, einer abgeleiteten Tabelle oder einer Unterabfrage-Bedingung der CREATE VIEW-Anweisung. Siehe CREATE VIEW-Anweisung.

Mindestkennwortlänge geändert   In früheren Versionen betrug die Mindestkennwortlänge standardmäßig 0 Zeichen. Der Standardwert für die Mindestkennwortlänge wurde auf 3 Zeichen geändert. Wenn Ihre Anwendung 0 Zeichen lange Kennwörter zulässt, können Sie die folgende Anweisung in einer neuen SQL Anywhere-Datenbank ausführen, um die Standardeinstellung an frühere Versionen anzupassen:

SET OPTION PUBLIC.min_password_length=0;

Weitere Hinweise finden Sie unter min_password_length-Option.

Standardverhalten beim Erstellen von Indizes für lokale temporäre Tabellen geändert   In früheren Versionen hat der Datenbankserver vor dem Erstellen eines Indexes für eine lokale temporäre Tabelle immer eine COMMIT-Anweisung ausgeführt. Nun führt der Datenbankserver vor dem Erstellen eines Indexes für eine lokale temporäre Tabelle keine COMMIT-Anweisung mehr aus. Sie können dieses Verhalten steuern, indem Sie die auto_commit_on_create_local_temp_index-Datenbankoption setzen. Siehe auto_commit_on_create_local_temp_index-Option.

Neue maximale Paketgröße   Die maximale Paketgröße wurde von 16000 auf 65535 Byte erhöht. Clients der Versionen SQL Anywhere 12 und früher sind auf 16000 Byte beschränkt, wenn sie Verbindungen mit SQL Anywhere 16-Datenbankservern herstellen. Die Standardpaketgröße wurde nicht geändert. Siehe Verbindungsparameter CommBufferSize (CBSIZE).

Grenze der Datenbankserveroption -ch geändert   Wenn Sie mit der Option -ch eine maximale Cachegröße angeben, die kleiner ist als 64 MB, passt der Datenbankserver die maximale Cachegröße auf 64 MB an. Wenn Sie eine maximale Cachegröße von weniger als 64 MB benötigen (wobei diese Einstellung nicht empfohlen wird), können Sie die Option -chx verwenden. Diese Änderungen gelten nicht unter Windows Mobile. Siehe Datenbankserveroption -ch .

Gleichzeitige Indexerstellung   In früheren Versionen musste die CREATE INDEX-Anweisung eine exklusive Tabellensperre setzen, wenn ein Index erstellt wurde. Nun setzt der Vorgang für kurze Zeiträume am Anfang und am Ende des Vorgangs eine exklusive Tabellensperre und für die meiste Zeit des Vorgangs eine gemeinsame Sperre, sodass andere Verbindungen auf die Tabelle zugreifen können, während der Index erstellt wird. Für die Verbindung, die den Index erstellt, wird der Zugriff auf die Tabelle blockiert, bis der Index erstellt ist. Sie müssen ein Upgrade bestehender Datenbanken durchführen, um diese Funktion verwenden zu können. Siehe CREATE INDEX-Anweisung.

Spiegelungsverbindungen können getrennt werden, wenn die Verbindungen das Übernehmen des Transaktionslogs verhindern   Verbindungen mit einem Kopieknoten oder der Spiegeldatenbank werden in manchen Fällen getrennt, wenn diese Verbindungen das Übernehmen des Transaktionslogs verhindern. Wenn beispielsweise eine Verbindung eine Prozedur verwendet, die das Transaktionslog zu ändern oder zu löschen versucht, wird die Verbindung getrennt, die das Übernehmen des Transaktionslogs blockiert, und eine Meldung wird in die Serverkonsole ausgegeben. Siehe Abfragen in der Spiegeldatenbank.

Änderungen am Plan-Caching   Abfrageausführungspläne werden für Abfragen mit langen Ausführungszeiten nicht in Cachespeicher geschrieben, weil die Vorteile durch das Vermeiden der Abfrageoptimierung im Vergleich zu den Gesamtkosten der Abfrage klein sind. Außerdem versucht der Datenbankserver nicht, wiederverwendbare Abfragepläne für Abfragen zu rekonstruieren, die sehr empfindlich auf die Werte ihrer Hostvariablen reagieren.

Neuer Standardwert für Anforderungsvariablen an HTTP-Server   In früheren Versionen gab es keine Grenze für die Anzahl von HTTP-Eingabevariablen, die in einer Anforderung gesendet werden konnten. Die MaxRequestVars-Protokolloption beschränkt die Anzahl von HTTP-Eingabevariablen. Der Standardwert für die MaxRequestVars-Protokolloption ist 10000. Siehe MaxRequestVars-Protokolloption (MAXVARS).

Neues Standardverhalten für Datenbankassertierungen   In früheren Versionen wurden Datenbank- Assertierungsfehler als Datenbankserver-Assertierungsfehler behandelt. Dies führte dazu, dass der Datenbankserver heruntergefahren wurde oder auf allen Clientverbindungen einen Fehler zurückgegeben hat. Datenbank-Assertierungsfehler werden nun getrennt von Datenbankserver-Assertierungsfehlern behandelt und führen dazu, dass die Datenbank heruntergefahren wird, während der Datenbankserver weiterläuft. Siehe Datenbankserveroption -ufd .

Verhaltensänderungen von gesicherten Funktionen   Schlüssel für gesicherte Funktionen haben nun eine Mindestlänge von 6 Zeichen und einige gesicherte Funktionen können nicht global deaktiviert werden, sondern nur für einzelne Verbindungen. Siehe Gesicherte Funktionen.

Vertrauliche Daten werden in der Ausgabe verschleiert   Kennwörter und Chiffrierschlüssel werden verschleiert, wenn Anweisungen, die sie enthalten, in das Anforderungslog geschrieben, durch die Diagnoseprotokollierung protokolliert oder von DESCRIBE-Anweisungen als Spaltennamen verwendet werden. Dieses Verhalten gilt auch für die Ausgabe der REWRITE-Funktion und der LastStatement-Verbindungseigenschaft sowie für in der Ereignisprotokollierung erfasste Anweisungen.

Vertrauliche Parameter sowie Kennwörter und Schlüssel werden für die folgenden Funktionen, Prozeduren und Anweisungen ausgeblendet:

• ENCRYPT-Funktion
• DECRYPT-Funktion
• sa_verify_password-Systemprozedur
• sp_addlogin-Prozedur (Adaptive Server Enterprise-Kompatibilitätsprozedur)
• sp_password-Systemprozedur
• xp_startmail-Systemprozedur
• xp_startsmtp-Systemprozedur
• sp_create_secure_feature_key-Systemprozedur
• sp_alter_secure_feature_key-Systemprozedur
• sp_use_secure_feature_key-Systemprozedur
• GRANT CONNECT-Anweisung
• CREATE DATABASE-Anweisung
• CREATE ENCRYPTED DATABASE-Anweisung
• CREATE ENCRYPTED TABLE DATABASE-Anweisung
• CREATE ENCRYPTED FILE-Anweisung
• CREATE DECRYPTED DATABASE-Anweisung
• CREATE DECRYPTED FILE-Anweisung
• START DATABASE-Anweisung
• DROP DATABASE-Anweisung
• CREATE EXTERNLOGIN-Anweisung
• SET TEMPORARY OPTION secure_feature_key = key-Anweisung

Lizenzierungsänderung für Personal Server (dbeng16)   Der Personal Server ist auf vier Prozessorkerne in einer CPU beschränkt. Bisher war der Personal Server auf eine CPU beschränkt. Siehe Dienstprogramm für die Serverlizenzierung (dblic).