<\/p>\n
André Minhorst, Duisburg<\/b><\/p>\n
Die Verwendung von Formularen und Unterformularen ist ein probates Mittel zur Darstellung von Daten aus 1:n- und m:n-Beziehungen. Dabei tritt immer wieder das ärgernis zu Tage, dass Access von Haus aus keine Möglichkeit mitbringt, änderungen an den Daten im Unterformular in einem Schritt mit denen des Hauptformulars rückgängig zu machen. Dieser Beitrag stellt eine Lösung vor, wie die Benutzer einer Datenbank dennoch mit einem Mausklick komplexe änderungen rückgängig machen können.<\/b><\/p>\nHinweis<\/h3>\n
Die Beispieldatenbanken zu diesem Beitrag heißen Forms.mdb und FormsAndSubforms.mdb. Sie finden die Datenbanken auf der Heft-CD oder im Internet unter http:\/\/www.access-im-unternehmen.de unter dem Shortlink 276. Nützliche Informationen gibt es im Beitrag Transaktionen in Access, Shortlink 275. <\/p>\n
Der Einsatz von Haupt- und Unterformularen ist durch die Verknüpfung der Datenherkünfte dieser beiden sehr hilfreich, ermöglicht er doch die Bearbeitung zusammenhängender Daten wie beispielsweise Bestellungen und bestellter Artikel (siehe Bild 1).<\/p>\n
![](\"..\/fileadmin\/_temp_\/{150CDBE5-F617-4842-A9D2-D8977567E725}\/pic001.png\")
<\/p>\n
<\/b><\/p>\n
Bild 1: Anzeige von Bestelldaten in Haupt- und Unterformular<\/span><\/b><\/p>\n Leider lassen diese Formulare eine sehr wichtige Eigenschaft vermissen: Sie bieten keine Undo-Funktion, die alle seit dem Anzeigen des Datensatzes im Hauptformular getätigten änderungen rückgängig macht. Es reicht gerade zu einer Undo-Funktion für den im Hauptformular angezeigten Datensatz. Wenn man einmal versehentlich den Hauptformular-Datensatz wechselt und änderungen an den Datensätzen im Unterformular vornimmt, ist dort maximal der letzte bearbeitete Datensatz noch zu retten. Den Rest können Sie aus dem Gedächtnis reproduzieren.<\/p>\n Wenn Sie nicht aus Sicherheitsgründen vor jeder Verwendung solcher Formulare eine Kopie der Datenbank anlegen möchten, lesen Sie weiter: Zum Warmmachen erfahren Sie zunächst, wie Sie änderungen in einem einfachen Formular vom öffnen des Formulars an verwerfen können, und dann geht es an die Unterformulare: Hier lernen Sie, wie Sie alle änderungen am aktuellen Datensatz des Hauptformulars und den verknüpften Datensätzen des Unterformulars mit einem Mausklick rückgängig machen – wenn Sie den Datensatz nicht zwischenzeitlich verlassen oder gespeichert haben.<\/p>\n Abhilfe schafft die Verwendung so genannter Transaktionen, mit denen man eine Abfolge von Datenbankaktionen zusammenfassen und entweder komplett übernehmen oder wieder verwerfen kann.<\/p>\n Der Beitrag Transaktionen in Access in der vorliegenden Ausgabe von Access im Unternehmen (oder unter http:\/\/www.access-im-unternehmen.de, Shortlink 275) beschreibt im Detail, wie Transaktionen funktionieren und wie man sie einsetzen kann. <\/p>\n Die wichtigsten Merkmale von Transaktionen in diesem Zusammenhang sind die, dass alle innerhalb einer Transaktion zu berücksichtigenden Vorgänge im Kontext eines Workspace-Objekts (DAO) oder eines Connection-Objekts (ADO) erfolgen müssen und dass alle auf diese Weise durchgeführten änderungen entweder komplett zu speichern oder komplett zu verwerfen sind.<\/p>\n Die Beispieldatenbanken enthalten zwei sehr einfach aufgebaute Tabellen. Die erste heißt tblKunden und enthält neben dem Primärschlüsselfeld KundeID lediglich das Feld Kundenname. Die zweite Tabelle heißt tblProjekte und besteht aus den Feldern ProjektID, Projekt und KundeID. Letzteres ist ein Fremdschlüsselfeld für die Verknüpfung mit der Tabelle tblKunden.<\/p>\n Die hier vorgestellten Techniken funktionieren nur unter Access 2000 und höher. <\/p>\n Bereits bei der Arbeit mit einem Formular kann es sinnvoll sein, alle seit dem öffnen des Formulars durchgeführten änderungen wieder rückgängig zu machen. Wie das funktioniert, erfahren Sie in nachfolgendem Beispiel.<\/p>\n Das hier verwendete Formular basiert auf der Tabelle tblKunden und zeigt lediglich die beiden Felder dieser Tabelle an (siehe Bild 2). Zusätzlich enthält das Formular eine Schaltfläche namens cmdOK und eine namens cmdAbbrechen.<\/p>\n Letztere soll dafür sorgen, dass alle seit dem öffnen des Formulars durchgeführten änderungen verworfen werden.<\/p>\n Bis Access 2000 gab es keine Möglichkeit, die während der Arbeit mit einem Formular ablaufenden Aktionen in einer Transaktion zusammenzufassen. Der Grund sind die bereits weiter oben beschriebenen Workspace- beziehungsweise Connection-Objekte, in deren Kontext die Transaktion abläuft. Gebundene Formulare arbeiten Datenoperationen außerhalb der üblichen Bereiche ab, sodass sich dort keine Transaktion starten lässt.<\/p>\n <\/b><\/p>\n Bild 2: Beispielformular für das formularweite Undo<\/span><\/b><\/p>\n Der Unterschied ab Version 2000, der dies erlaubt, ist die Möglichkeit der Verwendung von Recordset-Objekten als Datenherkunft von Formularen.<\/p>\n Das Beispielformular ist derzeit noch an die Tabelle tblKunden gebunden, da Sie diese Tabelle als Datenherkunft des Formulars festgelegt haben.<\/p>\n Ab Access 2000 können Sie das Formular auch an ein Recordset-Objekt binden, das die Daten dieser Tabelle enthält.<\/p>\n Um das nachzuvollziehen, leeren Sie einfach die Eigenschaft Datenherkunft des Formulars und legen für die Ereigniseigenschaft die Prozedur aus Quellcode 1 an.<\/p>\n Quellcode 1<\/b><\/p>\n Wenn Sie das Formular erneut öffnen, stellen Sie fest, dass es wie vorher die gewünschten Daten anzeigt.<\/p>\n Quellcode 2<\/b><\/p>\n Quellcode 3<\/b><\/p>\n Quellcode 4<\/b><\/p>\n Es gibt zwei Ereignisse, die beim ändern oder Löschen von Daten ausgelöst werden: Bei Geändert und Beim Löschen. Das Ereignis, das als Erstes ausgelöst wird, muss die Transaktion starten. Damit bei mehreren änderungen am Datenbestand nicht jedes Mal eine neue Transaktion gestartet wird, fragt die jeweilige Ereignisprozedur nach, ob schon eine Transaktion gestartet wurde. Für diesen Zweck legen Sie eine Variable namens bolDirty im Kopf des Moduls an:<\/p>\n Mit dieser Variable im Gepäck können Sie direkt die Prozeduren anlegen, die durch die Ereigniseigenschaften Bei Geändert und Beim Löschen ausgelöst werden (s. Quellcode 2). Die Prozeduren prüfen, ob die Variable bolDirty den Wert False hat, und starten in diesem Fall eine Transaktion.<\/p>\n <\/p>\n Schließlich legen Sie für die Schaltflächen cmdOK und cmdAbbrechen noch zwei Prozeduren an, die prüfen, ob eine Transaktion begonnen wurde, und diese gegebenenfalls beenden oder abbrechen.<\/p>\n Die OK-Schaltfläche löst die Prozedur aus Quellcode 3 aus. Da der Benutzer diese Schaltfläche möglicherweise anklickt, obwohl der aktuelle Datensatz zwar bearbeitet, aber noch nicht gespeichert ist, speichert die Prozedur den Datensatz zunächst. Anschließend prüft die Prozedur den Wert der Variablen bolDirty und damit, ob eine änderung durchgeführt und eine Transaktion ausgelöst wurde. Ist das der Fall, wird das Speichern der innerhalb der Transaktion durchgeführten änderungen ausgelöst.<\/p>\n Die Abbrechen-Schaltfläche soll alle änderungen, die seit dem öffnen des Formulars durchgeführt wurden, rückgängig machen.<\/p>\n Dies ist nur nötig, wenn entweder änderungen gespeichert wurden oder dies nicht der Fall ist und es offene änderungen gibt. In beiden Fällen sorgt die Rollback-Methode für das Verwerfen der vorgenommenen änderungen (s. Quellcode 4).<\/p>\n Probieren Sie das Formular nun aus. Wenn Sie etwa den Namen eines Kunden ändern und anschließend auf OK klicken, wird diese änderung gespeichert und beim nächsten öffnen wieder angezeigt. Klicken Sie auf Abbrechen und öffnen das Formular erneut, finden Sie den Datensatz unverändert vor.<\/p>\n Interessant wird es aber erst bei mehreren änderungen: Löschen Sie einen Datensatz, fügen Sie einen neuen hinzu und ändern Sie vorhandene Datensätze – mit einem Klick auf die Abbrechen-Schaltfläche und dem erneuten öffnen des Formulars finden Sie den alten Stand wieder vor.<\/p>\n Genauso nützlich wie das Verwerfen von änderungen mehrerer Datensätze in einem Formular ohne Unterformular ist die Vorgehensweise in Formularen mit Unterformular. Dabei kommt größtenteils die bereits beschriebene Technik zum Zuge, allerdings lässt sich die Lösung nur auf einen einzelnen Datensatz im Hauptformular und die verknüpften Datensätze im Unterformular ausführen.<\/p>\n Der Grund ist, dass wie bei dem vorherigen Beispiel eine Transaktion nur Datenbankoperationen innerhalb des angegebenen – in diesem Fall des aktuellen – Workspace berücksichtigen kann. Wie beim Hauptformular klappt dies auch in Unterformularen nur, wenn die Datenherkunft mittels Recordset-Objekt zugewiesen wird. Die Zuweisung muss bei jedem Datensatzwechsel im Hauptformular erneut durchgeführt werden.<\/p>\n Leider lässt sich der Recordset-Eigenschaft kein entsprechendes Objekt zuweisen, während eine Transaktion läuft. Daher müssen Sie auf den kompletten Komfort – also änderungen in mehreren Hauptformulardatensätzen plus den im Unterformular angezeigten Daten rückgängig zu machen – leider verzichten und mit dem Verwerfen der änderungen des aktuellen Datensatzes im Hauptformular und der verknüpften Daten im Unterformular vorlieb nehmen.<\/p>\n In einem Formular wie dem Bestellformular aus Bild 1 könnten Sie also nach Lust und Laune änderungen vornehmen und bestellte Artikel hinzufügen und wieder entfernen – nach einem Klick auf eine (hier nicht vorhandene) Abbrechen-Schaltfläche wäre alles wieder beim Alten.<\/p>\n Voraussetzungen<\/b><\/p>\n Für die Funktion der nachfolgend beschriebenen Technik müssen einige Voraussetzungen erfüllt sein:<\/p>\n Aufbau der Formulare<\/b><\/p>\n Das Hauptformular ist genauso wie das Formular aus dem vorherigen Beispiel aufgebaut. Erstellen Sie es zu Beispielzwecken neu oder kopieren Sie das vorhandene Formular und entfernen Sie den enthaltenen Code.<\/p>\n Das Unterformular sieht im Entwurf wie in Bild 3 aus. Zum Erstellen des Formulars stellen Sie zunächst die Datenherkunft auf die Tabelle tblKunden ein, ziehen alle Felder aus der Feldliste in den Detailbereich und löschen dann den für die Eigenschaft Datenherkunft angegebenen Wert – die Datenherkunft wird später dynamisch zugewiesen. Ordnen Sie die Steuerelemente wie in der Abbildung an.<\/p>\n <\/b><\/p>\n Bild 3: Entwurfsansicht des Unterformulars<\/span><\/b><\/p>\n Quellcode 5<\/b><\/p>\n Quellcode 6<\/b><\/p>\n <\/b><\/p>\n Bild 4: Haupt- und Unterformular in der Entwurfsansicht<\/span><\/b><\/p>\n Fügen Sie nun das Formular frmProjekte als Unterformular in das Formular frmKundenProjekte ein (siehe Bild 4).<\/p>\n VBA-Code der Formulare<\/b><\/p>\n Die Funktionalität des Formulars aus dem ersten Beispiel muss nun angepasst und auf das Unterformular ausgedehnt werden. Das bedeutet, dass Transaktionen nicht mehr nur aus dem Hauptformular, sondern auch aus dem Unterformular heraus gestartet werden können. Dementsprechend müssen auch die Variablen zum Speichern der Zustände (bolDirtyForm und bolSavedForm) in beiden Formularen verfügbar sein.<\/p>\n Eine öffentliche Deklaration ist nicht besonders vorteilhaft, daher verwenden Sie Property Get- und Property Set-Anweisungen für den Zugriff auf diese Variablen. Deren Deklaration erfolgt nach wie vor im Codemodul des Hauptformulars. Der erste Teil des Moduls enthält die in Quellcode 5 abgebildeten Zeilen.<\/p>\n öffnen des Hauptformulars<\/b><\/p>\n Das öffnen des Hauptformulars löst die Ereignisprozedur Form_Open aus. Die Prozedur stellt die Variablen db und wrk auf das aktuelle Database- und Workspace-Objekt ein und weist der Recordset-Eigenschaft des Formulars ein Recordset-Objekt mit der Tabelle tblKunden zu (s. Quellcode 6).<\/p>\n Anzeigen eines neuen Datensatzes<\/b><\/p>\n Quellcode 7<\/b><\/p>\n Quellcode 8<\/b><\/p>\n Quellcode 9<\/b><\/p>\n Quellcode 10<\/b><\/p>\n Das Ereignis Beim Anzeigen wird nach dem öffnen des Formulars und bei jedem Datensatzwechsel ausgelöst.<\/p>\n Damit tritt die entsprechende Prozedur vor allem immer dann in Aktion, wenn der Benutzer einen Datensatz verlässt und einen neuen anzeigt. Das ist Grund genug, den aktuellen Datensatz und die verknüpften Daten zu speichern und eine eventuell aktive Transaktion zu beenden.<\/p>\n Die Prozedur Form_Current tut dies, indem sie zunächst den Datensatz speichert, die Transaktion beendet und die Eigenschaft DirtyForm auf den Wert False zurücksetzt.<\/p>\n Außerdem stellt die Prozedur die Datenherkunft des Unterformulars so ein, dass die zu dem im Hauptformular angezeigten Kunden passenden Projekte angezeigt werden (s. Quellcode 7).<\/p>\n Dies passiert allerdings nur, wenn die Variable mDeletedForm den Wert True hat – wann das der Fall ist, erfahren Sie direkt im Anschluss.<\/p>\n Das Ereignis Bei änderung sorgt wie im vorherigen Beispiel dafür, dass die Eigenschaft DirtyForm auf den Wert True gesetzt und die Transaktion gestartet wird (s. Quellcode 8).<\/p>\n Das Ereignis Beim Löschen löst die Prozedur aus Quellcode 9 aus. Diese stellt lediglich die Variable mDeletedForm auf den Wert True ein.<\/p>\n Der Hintergrund für diese Variable ist, dass beim Löschen des Datensatzes im Hauptformular direkt zum nächsten verfügbaren Datensatz gewechselt wird.<\/p>\n Der Löschvorgang selbst dauert aber über den Datensatzwechsel (Form_Current) hinaus an, die beiden Ereignisse BeforeDelConfirm und AfterDelConfirm finden erst im Anschluss an die Anzeige des neuen Datensatzes statt. Da das Löschen selbst auch in einer (von Access gesteuerten) Transaktion stattfindet, würde das Wechseln des Recordset-Objekts des Unterformulars im Ereignis Beim Anzeigen des Formulars in diese Transaktion fallen und einen Fehler auslösen.<\/p>\n Daher müssen Sie das Aktualisieren des Unterformulars nach hinten verschieben – in das Ereignis Nach Löschbestätigung (s. Quellcode 10).<\/p>\n Diese ruft dann die Prozedur UnterformularAktualisieren auf, die für das Aktualisieren der Datenherkunft des Unterformulars verantwortlich ist.<\/p>\n Zwischenzeitlich löst Access auch noch das Ereignis Vor Löschbestätigung aus, in dem hier lediglich die Standardmeldung von Access unterbunden wird. Gegebenenfalls können Sie hier eine eigene Meldung integrieren (s. Quellcode 11).<\/p>\n Quellcode 11<\/b><\/p>\n Quellcode 12<\/b><\/p>\n Quellcode 13<\/b><\/p>\n Auch die Prozeduren, die durch die Schaltflächen cmdOK und cmdAbbrechen ausgelöst werden, unterscheiden sich lediglich durch den Bezug auf die entsprechenden Formulareigenschaften von denen des vorherigen Beispiels (s. Quellcode 12).<\/p>\n Quellcode 14<\/b><\/p>\n Da Haupt- und Unterformular nicht, wie sonst üblich, über die Eigenschaften Verknüpft von und Verknüpft nach miteinander verknüpft sind, müssen Sie den Inhalt des Unterformulars selbst aktualisieren. Dazu dient die Prozedur aus Quellcode 13, die beim Datensatzwechsel (Form_Current) und beim Löschen eines Datensatzes (Form_Delete) ausgelöst wird.<\/p>\n Datensatzänderungen im Unterformular werden zwar in der im Hauptformular gestarteten Transaktion berücksichtigt, aber sie lösen selbst keine Transaktion aus. Daher müssen änderungen im Unterformular ebenfalls eine Transaktion starten können, wenn noch keine Transaktion läuft.<\/p>\n Die dazu notwendigen Prozeduren sind in Form des kompletten Formularmoduls in Quellcode 14 abgebildet. Das Unterformular benötigt einen eigenen Verweis auf den aktuellen Workspace und verwendet die entsprechende Objektvariable in den Prozeduren Form_Delete und Form_Dirty, um eine Transaktion zu starten. Der Aufbau ähnelt den entsprechenden Prozeduren des Hauptformulars und wird hier nicht weiter erläutert.<\/p>\n Wichtig ist, dass die Prozeduren Form_Delete und Form_Dirty anhand der Eigenschaft DirtyForm des Hauptformulars ermitteln, ob schon eine Transaktion läuft und diese Eigenschaft auch entsprechend anpassen, wenn sie selbst eine Transaktion starten.<\/p>\n Mit der hier vorgestellten Technik können Sie Unterformulare in Undo-Funktionen einbeziehen und eine Abbrechen-Schaltfläche zumHauptformular hinzufügen, die ihren Namen zu Recht trägt.<\/p>\n Damit werden nicht nur die änderungen im Hauptformular, sondern auch alle änderungen an den verknüpften Datensätzen erfasst und gegebenenfalls verworfen.<\/p>\n In einer der nächsten Ausgaben lernen Sie eine Vereinfachung dieser Vorgehensweise kennen, die das Anlegen ein und desselben Codes in jedem einzelnen Formular umgeht.<\/p>\n Enthaltene Beispieldateien:<\/p>\n FormsAndSubforms.mdb<\/p>\nHinweis<\/h3>\n
Hinweis<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{150CDBE5-F617-4842-A9D2-D8977567E725}\/pic002.png\")
<\/p>\nPrivate Sub Form_Open(Cancel As Integer)\r\n Dim db As DAO.Database\r\n Dim rst As DAO.Recordset\r\n Set db = CurrentDb\r\n Set rst = db.OpenRecordset _ (\"tblKunden\", dbOpenDynaset)\r\n Set Me.Recordset = rst\r\nEnd Sub<\/pre>\n
Private Sub Form_Delete(Cancel As Integer)\r\n If bolDirty = False Then\r\n bolDirty = True\r\n DBEngine.BeginTrans\r\n End If\r\nEnd Sub\r\nPrivate Sub Form_Dirty(Cancel As Integer)\r\n If bolDirty = False Then\r\n bolDirty = True\r\n DBEngine.BeginTrans\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub cmdOK_Click()\r\n DoCmd.RunCommand acCmdSaveRecord\r\n If bolDirty = True Then\r\n DBEngine.CommitTrans\r\n End If\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
Private Sub cmdAbbrechen_Click()\r\n If bolDirty = True Then\r\n DBEngine.Rollback\r\n End If\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
Dim bolDirty As Boolean<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{150CDBE5-F617-4842-A9D2-D8977567E725}\/pic003.png\")
<\/p>\nOption Compare Database\r\nOption Explicit\r\nDim mDirtyForm As Boolean\r\nDim mDeletedForm As Boolean\r\nDim db As DAO.Database\r\nDim wrk As DAO.Workspace\r\nPublic Property Get DirtyForm() As Boolean\r\n DirtyForm = mDirtyForm\r\nEnd Property\r\nPublic Property Let DirtyForm (bolDirtyForm As Boolean)\r\n mDirtyForm = bolDirtyForm\r\nEnd Property<\/pre>\n
Private Sub Form_Open(Cancel As Integer)\r\n Dim rst As DAO.Recordset\r\n Set db = DBEngine(0)(0)\r\n Set wrk = DBEngine.Workspaces(0)\r\n Set rst = db.OpenRecordset(\"tblKunden\", _ dbOpenDynaset)\r\n Set Me.Recordset = rst\r\nEnd Sub<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{150CDBE5-F617-4842-A9D2-D8977567E725}\/pic004.png\")
<\/p>\nPrivate Sub Form_Current()\r\n Dim rst As DAO.Recordset\r\n If Me.DirtyForm = True Then\r\n DoCmd.RunCommand acCmdSaveRecord\r\n wrk.CommitTrans\r\n Me.DirtyForm = False\r\n End If\r\n If mDeletedForm = False Then\r\n UnterformularAktualisieren\r\n Else\r\n mDeletedForm = False\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub Form_Dirty(Cancel As Integer)\r\n If Me.DirtyForm = False Then\r\n Me.DirtyForm = True\r\n wrk.BeginTrans\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub Form_Delete(Cancel As Integer)\r\n mDeletedForm = True\r\nEnd Sub<\/pre>\n
Private Sub Form_AfterDelConfirm(Status As Integer)\r\n UnterformularAktualisieren\r\nEnd Sub<\/pre>\n
Keine Transaktion beim Löschen im Hauptformular<\/h3>\n
Private Sub Form_BeforeDelConfirm(Cancel As Integer, Response As Integer)\r\n Response = acDataErrContinue\r\nEnd Sub<\/pre>\n
Private Sub cmdAbbrechen_Click()\r\n If Me.DirtyForm = True Then\r\n wrk.Rollback\r\n End If\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub\r\nPrivate Sub cmdOK_Click()\r\n DoCmd.RunCommand acCmdSaveRecord\r\n If Me.DirtyForm = True Then\r\n wrk.CommitTrans\r\n End If\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
Private Sub UnterformularAktualisieren()\r\n Dim strSQL As String\r\n Dim rst As DAO.Recordset\r\n strSQL = \"SELECT * FROM tblProjekte \" & \"WHERE KundeID = \" & Nz(Me.KundeID, 0)\r\n Set rst = db.OpenRecordset(strSQL, dbOpenDynaset)\r\n Set Me.frmProjekte.Form.Recordset = rst\r\nEnd Sub<\/pre>\n
Aktualisieren des Unterformulars<\/h3>\n
Option Compare Database\r\nOption Explicit\r\nDim wrk As DAO.Workspace\r\nPrivate Sub Form_BeforeDelConfirm(Cancel As Integer, _ Response As Integer)\r\n Response = acDataErrContinue\r\nEnd Sub\r\nPrivate Sub Form_Delete(Cancel As Integer)\r\n If Me.Parent.DirtyForm = False Then\r\n Me.Parent.DirtyForm = True\r\n wrk.BeginTrans\r\n End If\r\nEnd Sub\r\nPrivate Sub Form_Dirty(Cancel As Integer)\r\n If Me.NewRecord Then\r\n Me.KundeID = Me.Parent.KundeID\r\n End If\r\n If Me.Parent.DirtyForm = False Then\r\n Me.Parent.DirtyForm = True\r\n wrk.BeginTrans\r\n End If\r\nEnd Sub\r\nPrivate Sub Form_Open(Cancel As Integer)\r\n Set wrk = DBEngine.Workspaces(0)\r\nEnd Sub<\/pre>\n
Transaktion auf das Unterformular erweitern<\/h3>\n
Downloads zu diesem Beitrag<\/h3>\n