Abhängig von der verwendeten Schnittstelle und dem Provider sowie davon, wie Sie das Autocommit-Verhalten steuern, verhält sich der Autocommit-Modus leicht unterschiedlich.
Der Autocommit-Modus kann auf zwei Arten implementiert werden:
Clientseitiges Autocommit Wenn eine Anwendung Autocommit verwendet, sendet die Clientbibliothek eine COMMIT-Anweisung nach jeder ausgeführten SQL-Anweisung.
ADO.NET-, ADO/OLE DB-, ODBC-, PHP- und SQL Anywhere JDBC-Anwendungen steuern das Festschreibeverhalten von der Clientseite.
Serverseitiges Autocommit Wenn eine Anwendung den chained-Modus deaktiviert, schreibt der Datenbankserver die Ergebnisse der einzelnen SQL-Anweisungen fest. Beim Sybase jConnect JDBC-Treiber wird dieses Verhalten durch die chained-Datenbankoption gesteuert.
Embedded SQL-, der jConnect-Treiber und Open Client-Anwendungen verändern das serverseitige Festschreibeverhalten (sie legen z.B. die chained-Option fest).
Bei zusammengesetzten Anweisungen wie gespeicherten Prozeduren oder Triggern gibt es einen Unterschied zwischen clientseitigem und serverseitigem Autocommit. Für den Client ist eine gespeicherte Prozedur eine einzelne Anweisung, und daher sendet Autocommit eine einzelne COMMIT-Anweisung, nachdem die gesamte Prozedur ausgeführt wurde. Aus der Perspektive des Datenbankservers kann die gespeicherte Prozedur aus vielen SQL-Anweisungen bestehen. Daher schreibt ein serverseitiges Autocommit die Ergebnisse der einzelnen SQL-Anweisungen innerhalb der Prozedur fest.
Clientseitige und serverseitige Implementierungen nicht vermischen. Kombinieren Sie die Einstellung der chained-Option nicht mit der Autocommit-Option in Ihrer ADO.NET-, OLE DB-, ODBC-, PHP- oder JDBC-Anwendung von SQL Anywhere.
 |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |