CONNECT-Anweisung (connect_statement) 

Eine CONNECT-Anweisung ( connect_statement ) eröffnet eine Datenbanksitzung und eine Transaktion eines Benutzers des Datenbanksystems.

parameter_name, password, user_name, unsigned_integer, termchar_set_name

Bei zulässiger Kombination der Werte von Parametername/Benutzername und Parametername/Kennwort eröffnet der Benutzer eine Datenbanksitzung und erhält Zugang zur Datenbankinstanz. Er ist damit der aktuelle Benutzer in dieser Sitzung.

Es wird implizit eine Transaktion eröffnet (siehe Transaktionen). Durch die COMMIT-Anweisung oder die ROLLBACK-Anweisung wird eine Transaktion beendet und implizit eine neue Transaktion eröffnet. Bei jedem Transaktionsende werden alle der Transaktion zugeordneten Sperren freigegeben, falls sie nicht durch ein KEEP LOCK gehalten werden. Für jede neu eröffnete Transaktion gilt das in der CONNECT-Anweisung angegebene Isolation-Level.

Jede CONNECT-Option ( connect_option ) darf nur einmal angegeben werden.

Mit der Angabe SQLMODE <INTERNAL | ANSI | DB2 | ORACLE> kann der SQL-Modus ausgewählt werden. Vorschlagswert ist der SQL-Modus INTERNAL.

Die CONNECT-Option SQLMODE <INTERNAL | ANSI | DB2 | ORACLE> ist innerhalb von Programmen nicht zulässig. Dort ist zur Angabe eines vom SQL-Modus INTERNAL abweichenden SQL-Modus die entsprechende Precompiler-Option zu verwenden.

Sperren (siehe Transaktionen) können implizit oder explizit angefordert werden. Die explizite Anforderung einer Sperre geschieht mittels der LOCK-Anweisung. Ob eine Sperre implizit angefordert wird oder explizit angefordert werden muß, hängt vom angegebenen Isolation-Level ab. Wie lange eine implizit gesetzte SHARE-Sperre gehalten wird, hängt ebenfalls vom Isolation-Level ab. Implizit gesetzte exklusive Sperren können innerhalb einer Transaktion nicht freigegeben werden. Die explizite Anforderung einer Sperre ist bei jedem Isolation-Level möglich.

• ISOLATION LEVEL 0: Es können Zeilen ohne Anforderung von SHARE-Sperren gelesen werden, d. h. implizit werden keine SHARE-Sperren angefordert. Daher ist auch nicht sichergestellt, daß die Zeile beim nochmaligen Lesen innerhalb der gleichen Transaktion noch den gleichen Zustand wie beim vorhergehenden Zugriff besitzt, da sie bereits durch eine konkurrierende Transaktion verändert worden sein kann.
  Außerdem ist nicht sichergestellt, daß der Zustand einer gelesenen Zeile bereits durch COMMIT WORK in der Datenbank festgeschrieben ist.
  Beim Einfügen, Ändern und Löschen von Zeilen werden der Transaktion implizit exklusive Sperren für die betroffenen Zeilen zugeordnet. Diese werden erst am Transaktionsende freigegeben.
• ISOLATION LEVEL 1 bzw. 10: Es wird der Transaktion eine SHARE-Sperre für eine gelesene Zeile Z1 einer Tabelle zugeordnet. Beim Lesen einer Zeile Z2 derselben Tabelle wird die Sperre auf Z1 freigegeben und der Transaktion wird eine SHARE-Sperre auf die Zeile Z2 zugeordnet.
  Bei der Datenanfrage mittels einer QUERY-Anweisung ist für jede gelesene Zeile sichergestellt, daß zu dem Zeitpunkt des Lesens dieser Zeile keiner anderen Transaktion eine exklusive Sperre auf diese Zeile zugeordnet ist. Es kann aber keine Aussage darüber getroffen werden, ob die QUERY-Anweisung keine oder genau eine SHARE-Sperre für eine Zeile der angegebenen Tabelle auslöst und für welche Zeile das gegebenenfalls geschieht.
  Beim Einfügen, Ändern und Löschen von Zeilen werden der Transaktion implizit exklusive Sperren für die betroffenen Zeilen zugeordnet, die erst am Transaktionsende freigegeben werden.
• ISOLATION LEVEL 15: Für alle SQL-Anweisungen, bei denen genau eine Zeile einer Tabelle über den Schlüssel gelesen wird, entspricht ISOLATION LEVEL 15 genau ISOLATION LEVEL 1 bzw. 10.
  Bei allen anderen SQL-Anweisungen gilt für ISOLATION LEVEL 15 das unter ISOLATION LEVEL 1 beschriebene Verhalten mit der Ergänzung, daß alle durch die SQL-Anweisung angesprochenen Tabellen vor Beginn der Bearbeitung SHARE gesperrt werden. Wenn durch die SQL-Anweisung eine Ergebnistabelle erzeugt wird, die nicht physisch abgespeichert wird, werden diese Sperren erst am Transaktionsende oder beim Schließen der Ergebnistabelle freigegeben, andernfalls erfolgt die Freigabe der Sperren unmittelbar nach der Bearbeitung der SQL-Anweisung.
  Beim Einfügen, Ändern und Löschen von Zeilen werden der Transaktion implizit exklusive Sperren für die betroffenen Zeilen zugeordnet, die erst am Transaktionsende freigegeben werden.
• ISOLATION LEVEL 2 bzw. 20: Alle durch die SQL-Anweisung angesprochenen Tabellen werden vor Beginn der Bearbeitung SHARE gesperrt. Wenn durch die SQL-Anweisung eine Ergebnistabelle erzeugt wird, die nicht physisch abgespeichert wird, werden diese Sperren erst am Transaktionsende oder beim Schließen der Ergebnistabelle freigegeben, andernfalls erfolgt die Freigabe dieser Sperren unmittelbar nach der Bearbeitung der SQL-Anweisung. Diese Tabellen-SHARE-Sperre wird der Transaktion nicht zugeordnet bei SQL-Anweisungen, bei denen genau eine Zeile einer Tabelle bearbeitet wird, die durch Schlüsselspezifikationen oder durch CURRENT OF <result_table_name> bestimmt wird.
  Darüber hinaus gilt, daß der Transaktion für jede während der Bearbeitung einer SQL-Anweisung gelesene Zeile implizit eine SHARE-Sperre zugeordnet wird. Diese können nur durch die UNLOCK-Anweisung oder durch Beendigung der Transaktion freigegeben werden.
  Beim Einfügen, Ändern und Löschen von Zeilen werden der Transaktion implizit exklusive Sperren für die betroffenen Zeilen zugeordnet, die erst am Transaktionsende freigegeben werden.
• ISOLATION LEVEL 3 bzw. 30: Der Transaktion wird für jede durch eine SQL-Anweisung angesprochene Tabelle implizit eine Tabellen-SHARE-Sperre zugeordnet. Diese können nur durch Beendigung der Transaktion freigegeben werden. Diese Tabellen-SHARE-Sperre wird der Transaktion nicht zugeordnet bei SQL-Anweisungen, bei denen genau eine Zeile einer Tabelle bearbeitet wird, die durch Schlüsselspezifikationen oder durch CURRENT OF <result_table_name> bestimmt wird.
  Beim Einfügen, Ändern und Löschen von Zeilen werden der Transaktion implizit exklusive Sperren für die betroffenen Zeilen zugeordnet, die erst am Transaktionsende freigegeben werden.
• Fehlt die Angabe eines Isolation-Level, wird ISOLATION LEVEL 1 angenommen.

• Phänomen 1: Dirty-Read-Phänomen
  In einer Transaktion T1 wird eine Zeile geändert und eine Transaktion T2 liest diese Zeile, bevor T1 durch die COMMIT-Anweisung abgeschlossen ist. T1 führt dann die ROLLBACK-Anweisung aus, d. h. T2 hat eine Zeile gelesen, die eigentlich nie existierte.
• Phänomen 2: Non-Repeatable-Read-Phänomen
  Eine Transaktion T1 liest eine Zeile. Eine Transaktion T2 verändert oder löscht dann diese Zeile und schließt mit der COMMIT-Anweisung ab. Wenn T1 anschließend die Zeile nochmals liest, erhält T1 entweder die veränderte Zeile oder die Meldung, daß die Zeile nicht mehr existiert.
• Phänomen 3: Phantom-Phänomen
  Eine Transaktion T1 führt eine SQL-Anweisung S aus, die eine Menge M von Zeilen liest, die eine Suchbedingung erfüllen. Eine Transaktion T2 erzeugt dann durch die INSERT-Anweisung oder die UPDATE-Anweisung mindestens eine weitere Zeile, die die Suchbedingung erfüllt. Wenn in T1 anschließend nochmals S ausgeführt wird, unterscheidet sich die Menge der gelesenen Zeilen von M.

Wird für den TIMEOUT-Wert 0 angegeben, so erfolgt keine Überprüfung der Inaktivitätsdauer. Das kann dazu führen, daß Datenbankressourcen nicht wieder zur Verfügung stehen, obwohl die zugehörige Anwendung schon, ggf. durch einen Abbruch, ohne eine RELEASE-Anweisung beendet wurde.

Terminal-Zeichensatzname

Benutzerhandbuch: SAP DB ® Begriffe ® Terminalunterstützung (Termchar-Sets)