Office: (Office 2010) Transactions

Hallo zusammen.

Ich hab ein neues Problem:
Da ist ein Formular mit 3 UFos. Die Daten kommen direkt aus 4 Tabellen (1 Haupt, 3 Untertabellen), deren Datensätze mit einer gemeinsamen Indexnummer verbunden sind. 1 Hauptsatz zu je mehreren Nebensätzen für die UFos.

Es hat 3 Knöpfe: Edit, Save und Cancel.
Wenn ich auf Edit clicke gebe ich die Eingabefelder frei für Änderungen.
Wenn ich Cancel drücke, möchte ich die Änderungen verwerfen. Für den Hauptsatz geht das mit Me.Undo. Die Änderungen in den UFos bleiben aber erhalten.

Ich dachte nun, man kann dies mit Transactions lösen, und zwar so:
Drücke ich Edit, mache ich .BeginTrans
Bei Save rufe ich dann .CommitTrans auf
Bei Cancel dann .Rollback, um alle Änderungen seit .BeginTrans rückgängig zu machen.

Klappt aber nicht so, wie ich mir das dachte. Das .Rollback scheint nicht zu funktionieren, denn die Änderungen in den UFO-Tabellen bleiben erhalten.

Warum? Was mache ich falsch?

:)

 

Transaktionen sind Methoden eines Workspace, um mal bei DAO zu verbleiben. DAO hat dann mit Accessformularen erst einmal gar nichts zu tun.

Mit anderen Worten: Wenn Du zu Hause den Herd ausschaltest, kann bei der Nachbarin trotzdem die Milch überkochen.

 

Wirklich? Na, sowas!
Ich dachte, mit Transaktionen kann ich meine überkochende Milch rückgängig machen, ganz egal, ob bei meiner Nachbarin der Herd explodiert.

Geht's irgendwie etwas weniger bildhaft, ohne Nachbars Milch?
Was mache ich falsch? Was versteh ich falsch?

 

Dass das eine mit dem anderen nichts zu tun hat, ist doch aber verständlich und abstrakt genug?

Eine Transaktion kann wirken auf DAO-Aktionen (Aktionsabfragen, Recordset) bzw. auch bei ADODB-Aktionen (ebenfalls Aktionsabfragen, Recordset).

Gebundene Formulare arbeiten anders. Sobald Du einen Datensatz im Formular verlässt (Datensatzwechsel, Wechsel auf anderes Formular, Schließen des Formulars oder der Anwendung) werden Änderungen am Datensatz gespeichert.
Falsche Entwürfe müsstest Du nachträglich wieder löschen.

 

Man müsste noch dazu sagen, dass die Anzeige im Form nicht den Daten in der Datenbank entsprechen muss. Nach einem Rollback müssen im Formular bereits geänderte Werte neu eingelesen werden. Genauso wenn man Daten im Form via VBA ändert, oder wenn sie durch einen anderen User geändert werden.

Bei einem Clientcursor müssen auch die Daten im Recordset neu eingelesen werden.

 

Hi Wof,

was dann noch zu erwähnen wäre ist, dass es nicht über drei Buttons gehen sollte.
In der Regel verwendest du Transaktionen wenn bei einem auftretenen Fehler ein Rollback erfolgen soll. Also zum Beipiel du siehst einen Lagerbestand von 3 Teilen und willst alle drei herausbuchen. Bevor du aber fertig bist, war ein anderer schneller. Die Transaktion prüft dann bevor der commit kommt ob der Lagerbestand negativ ist. (In der Regel darf er das nicht sein) Ist er das, dann kommt der Rollback und Du erhälst die Meldung : Ätsch da war einer schneller *Smilie
Oder wenn du über ein Netzwerk mit VPN arbeitest und es zu einem Verbindungsabruch kommen kann, damit kein Datensalat entsteht.
Oder beim erstellen von Rechnungen, damit da nichts verloren geht, wenn mehrere Berechnungen und Tabellen im Eingriff sind. etc.

Wenn Du das mit Transaktionen machst, dann läuft die Transaktion und nach dem commit musst Du deine Ufos aktualisieren umd die neuen Daten anzuzeigen. (Aber nicht den ersten button drücken, dann den zweiten etc.)

@Ebs

Der gefällt mir *Smilie (Sorry Wof)

VG
trekking

 

\@trekking:
Nichts zu entschuldigen. *Smilie

Ich habe auch versucht, mit dem Cancel-Button, der das Rollback auslöst, das Formular zu schließen, so dass es neu aufgerufen werden muss, um zu aktualisieren. Trotzdem waren die getätigten Änderungen an den Unterformular-Tabellen persistent. Es sieht also so aus, als ob das Rollback nicht funktioniert hätte.

@ebs:
Heißt das jetzt, dass ich an dieser Stelle nicht mit Transaction/Commit/Rollback arbeiten kann? Das würde die ganze Sache natürlich erheblich verkomplizieren.

Dass das eine nichts mit dem anderen zu tun hat leuchtet mir zunächst logisch nicht wirklich ein: Wenn ich eine Änderungsabfrage starte, dann bewirkt sie Änderungen in den Tabellen. Wenn ich vorher BeginTransaction sage und hinterher Rollback, dann sind die Änderungen wieder weg. Was soll der Unterschied dazu sein, wenn ich eine Änderung mit einem Formular durchführe und vorher BeginTrans gesagt habe?

Ich hab das früher schon in VB6 praktiziert. Da hatte ich eine Form, die Eingaben in verschieden Tabellen tätigte. Durch das BeginTrans/Rollback konnte ich beim Drücken auf den Cancel-Button jegliche getätigte Änderung verwerfen. Warum geht das bei Access nicht?

 

Accessformulare sind etwas anderes als MSForms.

Nimmt so etwas Eingang in Deine Gedankenwelt (man spürt nichts) oder ist das nur unnütze Füllmasse?

Wenn Du längerfristige Programmiererfahrung hast, ist Dir eventuell der Begriff Objekt kein absolutes Fremdwort ...? In dem Falle könntest Du Dir mit dem Objektkatalog (zu erreichen mit Taste F2 aus dem VBA-Editor heraus) ein Mittel zur Erleuchtung erschließen. Sonst natürlich auch, aber dann ist das Begreifen schwieriger, dass Methoden, die ein Objekt hat, nicht zwangsläufig dadurch bei allen anderen Objekten vorkommen werden.

Das kommt darauf an. Wenn Du Inhalte per Recordset oder Aktionsabfragen in Tabellen schiebst, dann wirst Du Transaktionen nutzen können.

Interessant wäre, was vor dem Punkt steht. Wenn Du da etwas geeignetes direkt am Accessformular findest, dann kannst Du es auch nutzen.

Nebenbei:

Eine typische Arbeitsweise wäre, Fakten in Stammdatentabellen zu bringen und zu verewigen. Etwas spielen und es sich dann anders überlegen ist eine andere Ebene.

 

Dieses Beispiel halte ich eher für ungeeignet. Der Zustand eines negativen Lagerbestandes kann durch einen einfachen Constraint bereits wirkungsvoll und einfacher verhindert werden.
Theoretischen Sinn würde das Beispiel ergeben, wenn du über eine Transaktion Lese- und Schreibkonsistenz zwischen der ersten und zweiten Operation herstellen würdest. - Ob das praktisch sinnvoll ist, sei mal dahingestellt.

Der Begriff "speichern" ist im Kontext von Transaktionen so unpräzise, dass eine Rückfrage dazu nicht nur gestattet sein sollte, sondern sogar dringend angeraten ist.

Es ist durchaus möglich die Änderung von Datensätzen in Formularen in einer Transaktion mit expliziten Commit oder Rollback durchzuführen. Der wesentliche Punkt dabei ist, dass man das Recordset des Formulars explizit selbst erstellt und zuweist, statt dies, wie üblich, Access zu überlassen.

Die Benutzeraktionen sowie das Verhalten der Benutzeroberfläche ist dabei nicht anders als mit der konventionellen Datenbindung.

 

\@Sonic
Ein Beispiel ist ein Beispiel um etwas zu erklären. Dafür taugt das Beipiel alle mal, da es kurz und einfach darstellt was eine Transaktion kann und in welcher Richtung man Transaktionen verwendet (Ohne Anspruch auf Vollständigkeit).
Dass viele Wege nach Rom führen ist hinreichend bekannt. Es kommt sicher darauf an, wie viele Tabellen im Eingriff sind, ob Access Standardfunktionen verwendet werden, ob ein SQL Server BE verwendet welche Schreibmethoden verwendet werden, wie die Information, dass der LAgerbestand unterschritten wird weiterverarbeitet wird und und und ....
Hätte natürlich eine wissenschaftliche Abhandlung darüber schreiben können mit einer Seitenweisen Asuführung und Links zu weiterführenden Themen. Aber wollen wir so etwas *Smilie

VG
trekking

 

Das hatte ich durchaus in meinen Aussagen auch ausgedrückt (zzgl. Aktionsabfragen), wenn auch nicht so durchformuliert. Zur präzisen Formulierung gehört dann aber auch, wenn man eingebaute Accessautomatik durch die genannte und im Detail anspruchsvolle eigene Programmierung austauscht, wird sehr schnell der Fall eintreten, dass man nicht nur Funktionalität gewinnt, sondern auch gewohnte andere Funktionalitäten verlieren kann - ich würde mich jedenfalls nicht darüber wundern.

Unabhängig von der technischen Umsetzbarkeit würde man wohl auch abwägen müssen, ob der getriebene Aufwand im Verhältnis dazu steht, ein paar (unbedachte?) Änderungen zurückzunehmen.
Wenn es denn notwendig und Schwerpunkt ist, probierend etwas zu tun und zum Ausgangspunkt zurückkehren zu können, gibt es weitere Möglichkeiten.

 

Denkfrage:
Transaktionen wird man zeitlich sehr kurz erledigen.
Wie kombiniert man das mit dem Eingabeverhalten eines Users in ein Formular mit mehreren Unterformularen, wo dann die Useraktion auch durch Telefonate, Besprechungen, Mittagspause uva. ausgedehnt werden kann?

 

\@sonic8,
toller Artikel auf deiner Website zu Transaktionen!!

@wof,
mit der Aussage, dass es nicht funktioniert hast du offensichtlich recht.
Da ich die Datenbasis immer per Recordset zuweise ist mir das auch nicht aufgefallen.

Wenn man jetzt überlegt was du aber tun möchtest, kann man nur sagen, zum Glück geht das auch nicht. Offensichtlich haben die Entwickler von Access da mitgedacht.

Folgendes Szenario:
Der Bearbeiter lösten den Start einer Transaktion zur Bearbeitung aus. Erstellt einen Datensatz. Jetzt kommt was Dringendes und er muss in diversen Formularen zwischenzeitlich was eingeben. Später kommt es in dem ursprünglichen Formular zu einem Rollback und es werden alle zwischenzeitliche Eingaben wieder gelöscht. Nicht grade toll oder.

Ich mache es grundsätzlich immer so:
Dabei habe ich leicht reden, denn ich bearbeite Datensätze nur in einem ungebundenen Formular.

Zuerst werden alle nötigen Daten für eine nennen wir es "Aufgabe" gesammelt.
Beim Anklicken von Speichern beginnt die Transaktion und alle Änderungen werden gebündelt durchgeführt.
Sollte es nicht möglich sein die gesamte Aufgabe auf einmal abzuschließen, weil es ein umfangreicher Prozess ist, dann unterteile ich den Prozess in Blöcke und jeder Block ermöglicht dann die notwendigen Anwender-Interaktionen und schließt auch jeweils die laufende Transaktion ab, so dass die Bearbeitung bei jedem Block abgebrochen werden kann und die Bearbeitung zu einem späteren Zeitpunkt automatisch an der richtigen Stelle fortfährt.

Falls jetzt irgend jemand das gelesen hat, würde es mich interessieren wie man das in einem gebundenen Formular durchführen kann, bzw wie ihr in der Praxis mit Transaktionen auf Form Ebene umgeht. Eberhard hat es ja nur als Frage in den Raum gestellt.

LG Markus

 

\@Markus
Hätte mal eine Frage an dich, da ich ja auch immer ungebunden arbeite. Wie handhabst du es bei einem Form mit UF? Wann speicherst du oder hast Du die Daten im UF in einem "Zwischenspeicher". Wie verfährst du mit dem endgültigen Schließen so eines Formulars, wenn der User Speichern Nein sagt?
Würde mich mal interessieren wie du es machst.

VG
trekking

 

Wenn das Öffnen des Recordsets dem Formular überlassen wird, ist es natürlich zu spät, eine Transaktion vorzuschalten. Trotzdem handelt es sich dabei um einen Mißbrauch von Transaktionen, die, wie Eberhard auch schon erwähnte, möglichst schnell abgeschlossen werden sollen.

Besser wäre es, ein temporäres lokales Scratch-Backend zu verwenden, aus dem man nach Verrichtung seiner Arbeit dann sinnvollerweise mittels Transaktion seine Daten an das eigentliche Ziel verschiebt und/oder löscht und/oder aktualisiert - oder einfach gar nichts macht.

Wenn die eigenen Asprüche nicht allzuhoch angesiedelt sind, lässt sich so eine Szenerie sogar mit einigen wenigen DoCmd-Anweisungen aufsetzen.