<\/p>\n
Die Durchführung von Aktualisierungen am Datenbestand wird umso fehleranfälliger, je mehr Schritten die jeweilige Aktion beinhaltet und je mehr Personen gleichzeitig auf den betroffenen Datenbestand oder Teilmengen davon zugreifen können. Transaktionen sind eine Technik, die in beiden Fällen für Sicherheit sorgen und Inkonsistenzen vermeinden helfen.<\/b><\/p>\n
Wofür Transaktionen<\/b><\/p>\n
Stellen Sie sich das einfache Beispiel einer Bank vor, in der ein Mitarbeiter einen Betrag von beispielsweise 100 Euro von einem Konto auf ein anderes umbucht. Dazu sind zwei Schritte erforderlich: Man muss dem ersten Konto die 100 Euro abziehen und diese dem zweiten Konto zuschreiben. Diese beiden Vorgänge müssen untrennbar miteinander verbunden sein; die Durchführung nur eines der Vorgänge würde zu einer Inkonsistenz führen. Entweder gibt es dann in der Gesamtbilanz irgendwo 100 Euro zuviel oder zuwenig – je nachdem, welcher Vorgang schiefgelaufen ist.<\/p>\n
Also benötigt man eine Technik, die mehrere Vorgänge „sammelt“ und entscheidet, ob die betreffenden änderungen durchzuführen sind oder verworfen werden.<\/p>\n
Im Datenbankbereich lassen sich Operationen als Transaktion zusammenfassen. Mit einer bestimmten Anweisung legt man fest, wann die Transaktion beginnt. Sind alle zusammenhängenden Aktionen erledigt, beendet man die Transaktion mit einer weiteren Anweisung. Erst dann wirken sich die durchgeführten änderungen auf den Datenbestand aus. Es gibt noch eine weitere Möglichkeit, eine Transaktion zu beenden: Wenn nicht alle enthaltenen Aktionen erfolgreich durchgeführt werden konnten, bricht man die Transaktion ab. In dem Fall werden alle der bis dahin durchgeführten änderungen am Datenbestand verworfen.<\/p>\n
Transaktionen in der Praxis<\/b><\/p>\n
Das obige Beispiel setzt voraus, dass theoretisch die Möglichkeit besteht, dass eine der innerhalb der Transaktion durchgeführten Aktionen scheitern könnte – das kann durchaus passieren, wenn etwa das Konto, von dem der Betrag abgebucht werden soll, nicht die notwendige Deckung aufweist. Kann man nicht einfach vor dem Durchführen der beiden Vorgänge prüfen, ob die Voraussetzungen erfüllt sind und erst dann die entsprechenden Aktionen durchführen<\/p>\n
Die Antwort lautet Jein. Wenn es sich bei dem System um eine Einzelplatzlösung handelt, wie es etwa bei einer Buchhaltungssoftware für Freiberufler der Fall sein dürfte (die sich in der Regel keinen Mitarbeiterstab für die Regelung ihrer Finanzen leisten), können sie locker auf die Verwendung von Transaktionen verzichten.<\/p>\n
Wenn es sich aber tatsächlich um eine Software handelt, die in einer Bank oder ähnlichen Institutionen eingesetzt wird, greifen unter Umständen mehrere Leute gleichzeitig auf ein und dasselbe Konto zu. Damit diese Vorgänge sich nicht überlappen, sperrt der erste Vorgang die relevanten Tabellen oder Datensätze und gibt diese erst nach Beendigung der Transaktion wieder frei. Die verwendeten Sperrmechanismen hängen dabei von den aktuell für diese Datenbank festgelegten Einstellungen ab. Wenn Sie optimistische Sperrung anwenden, sperrt eine Transaktion die betroffenen Datensätze erst beim Abschließen der Transaktion; beim pessimistischen Sperren hingegen beginnt die Sperre sofort mit dem Bearbeiten der Daten.<\/p>\n
Transaktionen und Aktionsabfragen<\/b><\/p>\n
Transaktionen können sich auf eine oder mehrere Tabellen beziehen. Bereits eine Aktionsabfrage zum Erhöhen aller Preise in einer Artikel-Tabelle kann Gegenstand einer Transaktion werden, wenn mehrere Datensätze daran beteiligt sind. Sie müssen allerdings bestimmte Regeln beachten, um die in Access eingebauten Transaktionsmechanismen zu nutzen.<\/p>\n
Zum Ausführen von Aktionsabfragen gibt es mehrere Möglichkeiten:<\/p>\n
Die ersten beiden Varianten sind identisch; das DoCmd<\/b>-Objekt verschafft dem Entwickler lediglich Zugriff auf die Menüelemente per VBA. Zu Beispielzwecken verwenden Sie eine Tabelle, die lediglich die beiden Felder ZahlID <\/b>und Zahl <\/b>enthält und unter dem Namen tblZahlen <\/b>gespeichert ist.<\/p>\n
Um Fehler während Transaktionen nachstellen zu können, stellen Sie die Feldgröße <\/b>des Feldes Zahl <\/b>auf Integer <\/b>und die Gültigkeitsregel <\/b>auf >0 <\/b>ein – so kann dieses Feld nur positive Zahlen aufnehmen (s. Bild 2 hinzu.<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2005_03\/Transaktionen_5-web-images\/pic001.png\")
<\/p>\n
Bild 1: Beispieltabelle tblZahlen<\/span><\/b><\/p>\n Bild 2: Beispielwerte in der Tabelle tblZahlen<\/span><\/b><\/p>\n Implizite Transaktion mit Aktionsabfragen und DoCmd.RunSQL<\/b><\/p>\n Rufen Sie dann im Direktfenster folgende Aktionsabfrage auf, die von den im Feld Zahl <\/b>enthaltenen Werten die Zahl 100 <\/b>subtrahiert:<\/p>\n <\/p>\n Mit der beschriebenen Beispielkonfiguration und obiger Anweisung sollten Sie eine Meldung wie in Bild 3 erhalten (zuvor kommt – je nach der Einstellung der Access-Optionen – noch eine Abfrage, ob Sie die Aktionsabfrage überhaupt durchführen möchten).<\/p>\n Bild 3: Bei Fehlern in Aktionsabfragen erscheint eine Meldung.<\/span><\/b><\/p>\n Die Meldung deutet darauf hin, dass Access zwar schon versucht hat, die Abfrage durchzuführen, aber dies noch nicht getan hat – sonst ließe sich diese nicht einfach rückgängig machen. Mit einem Klick auf Ja <\/b>führen Sie alle Teile der Abfrage durch, die nicht zu einem Fehler führen, mit einem Klick auf Nein <\/b>brechen Sie die Transaktion ab. Allerdings lösen Sie damit einen Fehler aus (s. Bild 4), um den Sie sich mit einer entsprechenden Fehlerbehandlung kümmern müssen.<\/p>\n Bild 4: Das Abbrechen einer mit DoCmd.RunSQL gestarteten Aktionsabfrage führt zu einem Fehler.<\/span><\/b><\/p>\n Keine implizite Transaktion mit der Execute-Methode<\/b><\/p>\n In einer professionellen Anwendung möchten Sie den Benutzer möglicherweise nicht mit so einer Meldung konfrontieren. Im besten Fall können Sie vorher abschätzen, welche Probleme beim Durchführen einer Aktionsabfrage auftreten können und legen direkt im Code entsprechende Maßnahmen fest.<\/p>\n Die Execute<\/b>-Anweisung des Database<\/b>– oder Connection<\/b>-Objekts erleichtert dies. <\/p>\n Die in der folgenden Prozedur verwendete Anweisung führt alle in der Aktionsabfrage enthaltenen Teile aus, die keinen Fehler auslösen:<\/p>\n Das bringt Sie auch nicht viel weiter, da der Benutzer nicht erfährt, das nicht alle gewünschten Operationen komplett ausgeführt wurden. Die folgende Variante unterscheidet sich lediglich durch den Parameter dbFailOnError <\/b>in der Execute<\/b>-Anweisung von der vorherigen Version:<\/p>\n Der Einsatz des Parameters dbFailOnError <\/b>sorgt dafür, dass Access bei Problemen mit der Aktionsabfrage entsprechende Fehlermeldungen ausgibt, wie das Beispiel aus Bild 5 zeigt.<\/p>\n Bild 5: Fehler beim Ausführen der Execute-Methode<\/span><\/b><\/p>\n Mit einer Fehlerbehandlung können Sie eigene Fehlermeldungen erzeugen und vor allem die Anwendung anschließend fortsetzen.<\/p>\n Aber ist die mit der Execute<\/b>-Methode abgesetzte SQL-Anweisung auch eine implizite Transaktion Werden bereits geänderte Datensätze beim Auftreten eines Fehlers wieder zurückgesetzt Ein Test ergibt: Nein! Probieren Sie die obige Prozedur einmal mit den Daten aus Bild 6 aus. Normalerweise sollte der erste Datensatz geändert werden, dann ein Fehler beim zweiten Datensatz auftreten, weil dessen Wert größer als 0 <\/b>sein muss und schließlich die änderungen verworfen werden.<\/p>\n Bild 6: Beispielkonfiguration zum Testen implizierter Transaktionen per Execute-Methode<\/span><\/b><\/p>\n Das Ergebnis sieht anders aus: Der Wert des ersten Datensatzes wird wie gewünscht geändert, aber der letzte Datensatz nicht – das heißt, dass diese scheinbare Transaktion nicht komplett durchgeführt, aber auch nicht rückgängig gemacht wurde.<\/p>\n Explizite Transaktionen mit DAO<\/b><\/p>\n Abhilfe schafft die Prozedur aus Listing 1<\/a>. Diese Prozedur verwendet eine explizite Transaktion und bettet die per Execute<\/b>-Anweisung abgesetzte Aktionsabfrage darin ein.<\/p>\n Listing 1: Beispiel für eine Transaktion mit einer Execute-Anweisung<\/p>\n Dazu erstellen Sie zunächst einen Verweis auf die aktuelle Sitzung, indem Sie mit der Objektvariablen wks den aktuellen Workspace referenzieren.<\/p>\n BeginTrans<\/b>, Commit <\/b>und Rollback <\/b>sind Methoden des Workspace<\/b>-Objekts:<\/p>\n Mit der BeginTrans<\/b>-Methode starten Sie die Transaktion innerhalb des Workspace<\/b>-Objekts. Die Execute<\/b>-Methode führt die Aktionsabfrage durch und sorgt mit dem dbFailOnError<\/b>-Parameter dafür, dass beim Auftreten eines Fehlers die Eigenschaften des Err<\/b>-Objekts mit entsprechenden Werten bestückt werden. Anschließend lässt sich mit dem Ausdruck Err.Number = 0 <\/b>leicht ermitteln, ob bei der Ausführung der Aktionsabfrage ein Fehler aufgetreten ist.<\/p>\n Ist das nicht der Fall, sorgt die Methode Commit <\/b>des Workspace<\/b>-Objekts dafür, dass die durch Execute<\/b>-Anweisung verursachten änderungen gespeichert werden, anderenfalls kommt die Rollback<\/b>-Methode zum Tragen und verwirft alle änderungen.<\/p>\n Ohne CommitTrans kein Speichern<\/b><\/p>\n Wenn der Gültigkeitsbereich des Workspace<\/b>-Objekts verlassen wird, ohne dass die Transaktion durch CommitTrans <\/b>abgeschlossen wurde, werden die änderungen automatisch verworfen.<\/p>\n Unterstützt ein Recordset Transaktionen<\/b><\/p>\n Die meisten ODBC-Datenquellen unterstützen Transaktionen. Wenn Sie sich nicht sicher sind, ob die Daten, die in einer Transaktion geändert werden sollen, dies auch unterstützen, können Sie dies mit der Eigenschaft Transactions <\/b>herausfinden. Mit einer Datensatzgruppe, auf die eine Objektvariable namens rst <\/b>verweist, funktioniert das folgendermaßen:<\/p>\n Schachtelung von Transaktionen<\/b><\/p>\n Sie können Transaktionen auf bis zu fünf Ebenen schachteln. Dabei müssen die von außen nach innen gestartet und von innen nach außen abgeschlossen werden. Sie können also auch die in einer Transaktion durchgeführten und abgeschlossenen Datenoperationen wieder rückgängig machen, indem Sie diese in eine weitere Transaktion einschließen.<\/p>\n Unvorhergesehene Laufzeitfehler<\/b><\/p>\n Falls Sie einmal auf einen Fehler treffen, den Sie nicht einordnen können, liegt es vielleicht daran, dass die Festplatte keinen Platz zum Anlegen der temporären Dateien mehr bietet. Die während einer Transaktion anfallenden Daten werden in einer temporären Datei zwischengespeichert. Diese Datei befindet sich in dem in der Temp-Umgebungsvariablen angegebenen Verzeichnis.<\/p>\n Explizite Transaktionen mit ADO<\/b><\/p>\n Auch ADO bietet die Möglichkeit expliziter Transaktionen. Dabei gibt es rein äußerlich zwei Unterschiede:<\/p>\n![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2005_03\/Transaktionen_5-web-images\/pic002.png\")
<\/p>\nDoCmd.RunSQL "UPDATE tblZahlen SET Zahl = Zahl - 100"<\/pre>\n
![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2005_03\/Transaktionen_5-web-images\/pic003.png\")
<\/p>\n![\"pic004.png\"](\"..\/fileadmin\/_temp_\/2005_03\/Transaktionen_5-web-images\/pic004.png\")
<\/p>\nPublic Sub Aktionsabfrage()\r\n Dim db As DAO.Database\r\n Set db = CurrentDb\r\n db.Execute "UPDATE tblZahlen SET Zahl = Zahl - 100"\r\n Set db = Nothing\r\nEnd Sub<\/pre>\n
Public Sub AktionsabfrageMF()\r\n Dim db As DAO.Database\r\n Set db = CurrentDb\r\n db.Execute "UPDATE tblZahlen SET Zahl = Zahl - 100", dbFailOnError\r\n Set db = Nothing\r\nEnd Sub<\/pre>\n
![\"pic005.png\"](\"..\/fileadmin\/_temp_\/2005_03\/Transaktionen_5-web-images\/pic005.png\")
<\/p>\n![\"pic006.png\"](\"..\/fileadmin\/_temp_\/2005_03\/Transaktionen_5-web-images\/pic006.png\")
<\/p>\nPublic Sub ExecuteMitTransaktion()\r\n Dim db As DAO.Database\r\n Dim wks As DAO.Workspace\r\n On Error Resume Next\r\n Set wks = DBEngine.Workspaces(0)\r\n wks.BeginTrans\r\n Set db = CurrentDb\r\n db.Execute "UPDATE tblZahlen SET Zahl = Zahl - 100", dbFailOnError\r\n If Err.Number = 0 Then\r\n wks.CommitTrans\r\n MsgBox "OK"\r\n Else\r\n wks.Rollback\r\n MsgBox "Abgebrochen"\r\n End If\r\n Set db = Nothing\r\n Set wks = Nothing\r\nEnd Sub<\/pre>\n
\n
Debug.Print rst.Properties("Transactions")<\/pre>\n\n