<\/p>\n
Das Problem beim Einsatz von Haupt- und Unterformularen mit Daten aus verknüpften Tabellen ist, dass der Benutzer diese als Einheit ansieht. Enthält das Hauptformular eine Abbrechen-Schaltfläche, geht er davon aus, dass er die änderungen an Daten im Haupt- oder Unterformular damit komplett rückgängig machen kann. Leider ist das nicht so – die änderungen im Unterformular bleiben gespeichert, und auch die Werte im Hauptformular lassen sich nach dem Speichern etwa durch einen Mausklick auf den Datensatzmarkierer nicht mehr rückgängig machen. Grund genug, unsere bereits einmal beschriebene Technik nochmal unter die Lupe zu nehmen und in eine flexibel einsetzbare Klasse zu exportieren.<\/b><\/p>\n
Beispieltabellen und -formulare<\/b><\/p>\n
Im Rahmen dieses Beitrag verwenden wir die Tabellen der Südsturm-Datenbank, genau genommen die Tabellen tblBestellungen<\/b>, tblKunden<\/b>, tblBestelldetails <\/b>und tblArtikel<\/b>. Außerdem erstellen wir zunächst ein Hauptformular namens frmBestellungen <\/b>und ein Unterformular namens sfmBestellungen<\/b>, um die herkömmliche Situation zu betrachten.<\/p>\n
Später statten wir ähnliche Formulare mit einem Klassenmodul und dessen Methoden und Eigenschaften aus, um das Undo sowohl im Haupt- als auch im Unterformular zu ermöglichen.<\/p>\n
Die an der Beispiellösung beteiligten Tabellen finden Sie in der übersicht aus Bild 1. Direkt in die Formulare eingebunden werden dabei nur die beiden Tabellen tblBestellungen <\/b>und tblBestelldetails<\/b>, die Daten der Tabelle tblKunden <\/b>stehen im Hauptformular als Daten eines Kombinationsfeldes zur Verfügung, die Daten der Tabelle tblArtikel <\/b>in einem Kombinationsfeld im Unterformular.<\/p>\n
![\"Tabellen](\"..\/fileadmin\/_temp_\/2013_06\/pic_912_001.png\")
<\/p>\n
Bild 1: Tabellen der Beispieldatenbank<\/span><\/b><\/p>\n Ausgangssituation<\/b><\/p>\n Wir wollen ein Element der Benutzeroberfläche einer Anwendung optimieren, das im Hauptformular jeweils einen Datensatz der Tabelle tblBestellungen <\/b>anzeigt und im Unterformular die damit verknüpften Datensätze der Tabelle tblBestelldetails<\/b>. Dazu weisen Sie einfach der Eigenschaft Datenherkunft von Haupt- und Unterformular die beiden Tabellen tblBestellungen <\/b>und tblBestelldetails <\/b>zu.<\/p>\n Das Hauptformular soll in diesem Fall die Felder BestellungID<\/b>, KundeID<\/b>, Bestelldatum<\/b>, Lieferdatum <\/b>und Versanddatum <\/b>der Tabelle tblBestellungen <\/b>enthalten, das Unterformular die Felder ArtikelID<\/b>, Einzelpreis<\/b>, Anzahl<\/b>, Rabatt <\/b>und BestellungID <\/b>der Tabelle tblBestelldetails<\/b>.<\/p>\n In der Entwurfsansicht sieht der Aufbau der beiden Formulare nun wie in Bild 2 aus. Das Unterformularsteuerelement haben wir sfm <\/b>genannt, damit wir es später im Code vom eingebetteten Unterformular sfmBestellungen <\/b>unterscheiden können.<\/p>\n Bild 2: Haupt- und Unterformular in der Entwurfsansicht<\/span><\/b><\/p>\n Die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformularsteuerelements sfm <\/b>enthalten beide den Namen des Feldes BestellungID<\/b>. Auf diese Weise zeigt das Unterformular jeweils die zum Datensatz des Hauptformulars passenden Daten an. Das Hauptformular enthält noch zwei Schaltflächen. cmdOK <\/b>löst diesen Code aus:<\/p>\n Damit schließt sie das Formular und speichert den aktuellen Zustand der Daten. Die zweite Schaltfläche enthält die Beschriftung Abbrechen <\/b>oder, in diesem Fall, Verwerfen<\/b>. Sie führt lediglich die Undo<\/b>-Methode des Hauptformular aus und verwirft somit die änderungen seit dem letzten Speichern im Hauptformular:<\/p>\n Dies ist für den Benutzer mitunter irreführend, da er den Eindruck erhalten kann, dass sich mit einer solchen Schaltfläche alle seit dem letzten öffnen getätigten änderungen verwerfen lassen. Dies ist mitnichten so: änderungen im Unterformular werden auf keinen Fall verworfen, denn diese werden spätestens dann in der zugrunde liegenden Tabelle gespeichert, wenn das Unterformular den Fokus verliert. Und das ist zwangsläufig der Fall, wenn der Benutzer ein Steuerelement des Hauptformulars betätigt, in diesem Fall die Verwerfen<\/b>-Schaltfläche.<\/p>\n Andersherum wird der Datensatz im Hauptformular sofort gespeichert, wenn der Benutzer den Fokus in das Unterformular verschiebt. Beim klassischen Fall, also dem Anlegen der grundlegenden Bestelldaten wie Kunde, Bestelldatum et cetera und dem anschließenden Hinzufügen von Bestellpositionen bewirkt das Betätigen der Verwerfen<\/b>-Schaltfläche schlicht und einfach nichts. Zu diesem Zeitpunkt sind alle Daten bereits gespeichert. Da die Undo<\/b>-Methode genau die gleiche Wirkung hat wie das Betätigen der Escape-Taste, macht auch diese keine der getätigten und gespeicherten Eingaben mehr rückgängig.<\/p>\n Dies wollen wir nun ändern – und zwar mit einer Klasse, die alle dazu nötigen Funktionen enthält. Das Ganze ist nicht gerade trivial, denn wir müssen einige Fälle beachten. Bei der Programmierung einer solchen Klasse wird man kaum auf einen Schlag alle denkbaren Konstellationen erschlagen. Man beginnt also damit, einfache Vorfälle abzudecken, und programmiert deren Behandlung. Wenn dies funktioniert, schaut man sich den nächsten Vorfall an und programmiert weiter.<\/p>\n Beim Testen des Programmierfortschritts sollte man jedoch auch immer wieder die vorher behandelten Vorfälle testen. Damit stellen Sie sicher, dass Sie durch das Hinzufügen oder ändern des bestehenden Codes die bereits vorhandene Funktionalität beeinflussen.<\/p>\n Grundsätzlich soll die Klasse dafür sorgen, dass alle seit dem öffnen eines Datensatzes getätigten änderungen mit einem Klick auf die Verwerfen<\/b>-Schaltfläche wieder rückgängig gemacht werden können.<\/p>\n Es gibt eine Ausnahme: Das Löschen einer kompletten Bestellung, also eines Datensatzes der Tabelle tblBestellungen <\/b>und damit auch aller damit verknüpften Datensätze der Tabelle tblBestellpositionen<\/b>. In dem Moment, in dem der Benutzer den Datensatz im Hauptformular löscht, spielt es keine Rolle mehr, ob die bisherigen änderungen der Transaktion durchgeführt werden oder nicht.<\/p>\n Tests festlegen<\/b><\/p>\n Um zu prüfen, ob alles jederzeit wie gewünscht funktioniert, legen wir einige Tests zurecht – diese sollten alle paar neuen Codezeilen geprüft werden, um vorzeitig ein Programmieren in die falsche Richtung zu verhindern:<\/p>\n Am schönsten wäre es natürlich, wenn man solche und ähnliche Tests der Benutzeroberfläche automatisch ablaufen lassen könnte. Dies ist jedoch sehr aufwendig zu realisieren. Gegebenenfalls kümmern wir uns zu einem späteren Zeitpunkt um ein entsprechendes Tool.<\/p>\n Transaktionen<\/b><\/p>\n Der Wechsel zum Unterformular speichert bereits die Daten im Hauptformular und der Wechsel von einem Datensatz zum nächsten im Unterformular das Gleiche mit den Datensätzen im Unterformular. Wie wollen wir dann dafür sorgen, dass die vollständigen änderungen am aktuellen Datensatz im Hauptformular samt den verknüpften Daten im Unterformular rückgängig gemacht werden können<\/p>\n Dafür gibt es verschiedene Ansätze. Der erste wäre, den aktuellen Datensatz im Hauptformular vor der Bearbeitung im Hauptformular in einer temporären Tabelle zu speichern – ebenso wie die Daten des Unterformulars. Beim Mausklick auf die Schaltfläche OK <\/b>werden dann alle Daten in die Originaltabellen übertragen, beim Anklicken von Verwerfen <\/b>löschen wir einfach die Daten der temporären Tabellen.<\/p>\n Der zweite Ansatz verwendet Transaktionen. Das bedeutet, dass wir bei der ersten änderung an dem im Hauptformular angezeigten Datensatz oder an einem der Datensätze im Unterformular eine Transaktion starten müssen. Das gilt natürlich auch dafür, wenn wir im Hauptformular einen neuen Datensatz anlegen oder Datensätze zum Unterformular hinzufügen.<\/p>\n Der Einsatz von Transaktionen ist recht einfach: Sie definieren eine Workspace-Variable, die den Workspace der aktuellen Datenbank referenziert (mit DBEngine.Workspaces(0)<\/b>. Dieses Workspace-Objekt stellt dann die folgenden drei Methoden zur Verfügung:<\/p>\n Nun muss man allerdings wissen, welche änderungen vom Start der Transaktion an protokolliert werden und entsprechend rückgängig gemacht werden können. Dabei handelt es lediglich um solche Transaktionen, die über das Database<\/b>-Objekt der aktuellen Datenbank durchgeführt wurden. Wenn Sie also etwa nach dem Aufruf von BeginTrans <\/b>mit der db.Execute<\/b>-Methode eine Aktionsabfrage durchführen oder die Daten eines DAO-Recordsets mit Edit<\/b>\/AddNew <\/b>und Update <\/b>ändern, können Sie diese änderungen durch CommitTrans <\/b>speichern oder durch Rollback <\/b>verwerfen.<\/p>\n Dummerweise laufen die änderungen, die Sie an den Daten eines über die Eigenschaft Datenherkunft <\/b>an eine Datenquelle gebundenen Formulars durchführen, nicht im Kontext einer Transaktion. Und hier wird es interessant: Sie können ein Formular nämlich auch über die Recordset<\/b>-Eigenschaft mit den Daten aus einer Tabelle oder Abfrage füllen. Und wenn Sie dieses Recordset im Kontext einer Transaktion mit OpenRecordset <\/b>erstellen und der Datenherkunft des Formulars beziehungsweise des Unterformulars zuweisen, können Sie auch die änderungen am Formular durch ein Rollback <\/b>verwerfen oder durch ein CommitTrans <\/b>speichern.<\/p>\n Das hat allerdings auch kleinere Nachteile: Normalerweise weisen Sie dem Hauptformular die eine Tabelle der 1:n-Beziehung als Datenherkunft zu und dem Unterformular die andere Tabelle. Dabei stellen Sie die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformular-Steuerelements auf das Fremdschlüsselfeld im Unterformular und das Primärschlüsselfeld im Hauptformular ein, damit das Unterformular jeweils die passenden Daten zum Hauptformular anzeigt.<\/p>\n Wenn Sie Haupt- und Unterformular jedoch etwa im Ereignis Beim Laden <\/b>des Hauptformulars mit den zuvor erstellten Recordset<\/b>-Objekten versehen, sind die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>wirkungslos. Deshalb müssen Sie dem Unterformular beim Wechsel des Datensatzes im Hauptformular jeweils ein neues Recordset zuweisen, dass die zum Datensatz im Hauptformular passenden Datensätze enthält.<\/p>\n So schlimm ist das aber auch nicht – wir müssen diesen Vorgang ja auch nur einmal programmieren.<\/p>\n Formular anpassen<\/b><\/p>\n Nachdem wir wissen, dass wir das Formular und das Unterformular mit einer Klasse ausstatten wollen, die dafür sorgt, dass änderungen an den kompletten angezeigten Daten des aktuellen Datensatzes des Hauptformulars durch einen Mausklick auf eine Schaltfläche rückgängig gemacht werden, bereiten wir zunächst das Formular vor.<\/p>\n Formular und Unterformular erstellen<\/b><\/p>\n Grundsätzlich sollten Haupt- und Unterformular zunächst mit den Tabellen oder Abfragen als Datenherkunft ausgestattet werden, die sie im normalen Betrieb verwenden würden.<\/p>\n Dies geschieht aus reiner Bequemlichkeit: Wir können so nämlich die Steuerelemente der jeweiligen Datenherkunft aus der Feldliste in die gewünschten Bereiche des Formulars ziehen. Danach leeren wir einfach die Eigenschaft Datenherkunft <\/b>des Formulars.<\/p>\n Auf die gleiche Weise gehen wir beim Unterformular vor. Hier ist darauf zu achten, dass Sie auch die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformular-Steuerelements leeren (s. Bild 3).<\/p>\n Bild 3: Die Verknüpfungseigenschaften zwischen Haupt- und Unterformular werden geleert.<\/span><\/b><\/p>\n Klasse erstellen<\/b><\/p>\n Anschließend erstellen wir schon das Klassenmodul (VBA-Editor, Einfügen|Klassenmodul<\/b>). Dieses nennen wir schlicht und einfach clsUndo<\/b>.<\/p>\n Normalerweise hätten wir die Ereignisse, die dazu führen, dass eine Transaktion gestartet, beendet oder verworfen wird, direkt in den Klassenmodulen des Haupt- und des Unterformulars untergebracht. Dann müssten Sie diesen Code jedoch, wenn Sie diesen in einem anderen Formular weiterverwenden wollten, jeweils in das entsprechende Klassenmodul des Formulars\/Unterformulars übertragen.<\/p>\n Wenn Sie eine solche Funktionalität einmal programmiert haben und diese dann auf einen anderen Anwendungsfall übertragen möchten, sind meist individuelle Anpassungen nötig – was zu Fehlern führen kann, insbesondere dadurch bedingt, dass man nicht mehr genau weiß, an welchen Schrauben man wie drehen muss. Wenn Sie hingegen die komplette Funktion in einem eigenen Klassenmodul kapseln und dieses von dem damit auszustattenden Formular einfach nur instanzieren und mit einigen Eigenschaften ausstatten müssen, haben Sie leichtes Spiel.<\/p>\n Referenzen an das Klassenmodul übergeben<\/b><\/p>\n Die Ereignisse, Variablen und Prozeduren, die Sie normalerweise im Klassenmodul des betroffenen Formulars angelegt hätten, deklarieren Sie nun komplett im Klassenmodul clsUndo<\/b>. Dabei ist allerdings zu beachten, dass dieses ja nicht weiß, auf welches Formular es sich beziehen soll. Genauso weiß es nicht, welches Unterformular betroffen ist (wenn mehrere vorhanden sind) und welche Schaltflächen für das übernehmen oder Verwerfen der änderungen verantwortlich sind.<\/p>\n Damit wir der Klasse beim Laden des Formulars die benötigten Informationen übergeben können, legen wir in der Klasse zunächst einige Variablen fest, welche die Verweise auf diese Objekte speichern sollen. Dies sieht wie folgt aus:<\/p>\n Wir benötigen also zwei Variablen des Typs Form <\/b>und zwei des Typs CommandButton<\/b>. Für alle vier Objekte wollen wir innerhalb des Klassenmoduls clsUndo <\/b>eigene Ereignisprozeduren implementieren. Das geschieht prinzipiell genauso wie im Klassenmodul eines Formulars, allerdings steht die einfache Möglichkeit zum Erstellen solcher Ereignisprozeduren durch Eintragen des Wertes [Ereignisprozedur] <\/b>in die jeweilige Ereigniseigenschaft und anschließendes Klicken auf die Schaltfläche mit den drei Punkten (…) rechts neben der Eigenschaft nicht zur Verfügung.<\/p>\n Bliebe noch die Möglichkeit, die entsprechenden Objektvariablen im linken Kombinationsfeld des VBA-Editors auszuwählen und das passende Ereignis aus dem rechten Kombinationsfeld zu ergänzen. Das gelingt aber auch nur unter einer Bedingung: Wenn die passende Objektvariable mit dem WithEvents<\/b>-Schlüsselwort deklariert wurde – und genau dies erledigen wir wie folgt:<\/p>\n Anschließend fügen Sie über die beiden Kombinationsfelder im Codefenster die benötigten Ereignisprozeduren hinzu (s. Bild 4).<\/p>\n <\/p>\n Bild 4: Hinzufügen einer Ereignisprozedur für eine mit WithEvents deklarierte Objektvariable<\/span><\/b><\/p>\n Wie gelangen aber nun die Verweise auf die entsprechenden Elemente des Formulars in diese Variablen – und wie sorgen wir dafür, dass das Formular weiß, dass es im Klassenmodul clsUndo <\/b>noch Prozeduren gibt, die beim Eintreten verschiedener Ereignisse des Formulars, des Unterformulars oder der beiden Schaltflächen ausgelöst werden sollen Dies geschieht in drei Schritten:<\/p>\n Prozeduren als Eigenschaften<\/b><\/p>\n Legen wir zunächst die vier Property Set<\/b>-Prozeduren in der Klasse clsUndo <\/b>an. Diese erscheinen dann später im Klassenmodul des Formulars, das die Klasse clsUndo <\/b>instanziert, als Eigenschaften des Klassenobjekts.<\/p>\n Wir beginnen mit den beiden Schaltflächen zum Speichern und zum Verwerfen der änderungen.<\/p>\n Die OK<\/b>-Schaltfläche soll über die folgende Property Set<\/b>-Prozedur an die Klasse clsUndo <\/b>übergeben werden:<\/p>\n Die Zeilen dieser Prozedur weisen zunächst die mit dem Parameter cmd <\/b>übergebene Schaltfläche der weiter oben mit dem Parameter WithEvents <\/b>deklarierten Variablen m_CancelButton <\/b>zu. Die folgende Anweisung entspricht dem Einstellen der Ereigniseigenschaft Beim Klicken <\/b>auf den Wert [Ereignisprozedur]<\/b>.<\/p>\n Die folgende Property Set<\/b>-Prozedur erledigt das Gleiche für die Schaltfläche, mit der eventuelle änderungen an den Daten im Haupt- oder Unterformular verworfen werden sollen:<\/p>\n Nun schauen wir uns die Prozedur an, welche mit dem Parameter frm <\/b>den Verweis auf das Unterformular entgegennimmt. Dieser landet in der Variablen m_Subform<\/b>. Für das Unterformular stellt die Prozedur gleich eine ganze Reihe Ereigniseigenschaften auf den Wert [Event Procedure] <\/b>ein (dies ist der eigentliche Wert – im Eigenschaftsfenster erscheint dann gegebenenfalls [Ereigniseigenschaft]<\/b>). Die Prozedur finden Sie in Listing 1.<\/p>\n Listing 1: Property Set-Prozedur zum übergeben des Verweises auf das Unterformular<\/span><\/b><\/p>\n Die Property Set<\/b>-Methode für die übergabe des Verweises auf das Hauptformular ist die aufwendigste: Sie erwartet mit dem Parameter frm <\/b>den Verweis auf das Hauptformular. Diesen speichert sie alsbald in der privat deklarierten Variablen m_Form<\/b>. Für m_Form<\/b> legt sie dann die Ereigniseigenschaften fest, die im Klassenmodul clsUndo <\/b>implementiert werden sollen (s. Listing 2).<\/p>\n Listing 2: Zuweisen des Verweises auf das Hauptformular plus einige weitere Aktionen<\/span><\/b><\/p>\n Außerdem folgen noch eine ganze Reihe weiterer Aktionen, die normalerweise im Form_Load<\/b>-Ereignis des Formulars ausgeführt werden müssten. Allerdings können wir dieses Formular nicht im Klassenmodul implementieren, weil das Klassenmodul selbst ja erst im Form_Load<\/b>-Ereignis des Formulars instanziert wird. Sprich: Das Ereignis Form_Load <\/b>ist dann bereits abgehakt und wird im Gegensatz zu einigen anderen Ereignissen wie etwa Form_Current <\/b>(Beim Anzeigen<\/b>) nicht erneut aufgerufen.<\/p>\n Dabei weist die Prozedur zunächst der wie folgt im Kopf des Moduls clsUndo <\/b>deklarierten Objektvariablen db <\/b>einen Verweis auf die aktuell geöffnete Datenbank zu:<\/p>\n Außerdem füllt sie ein Objekt namens wrk <\/b>mit einem Verweis auf den aktuellen Workspace. Das Workspace<\/b>-Objekt stellt ja, wie oben erläutert, die Methoden zum Starten, Beenden und Abbrechen der Transaktion zur Verfügung. wrk <\/b>wird wie folgt deklariert:<\/p>\n Außerdem öffnet die Prozedur ein Recordset auf Basis der in der Variablen m_RecordsourceForm <\/b>gespeicherten Datenherkunft für das Hauptformular.<\/p>\n Die Deklaration dieser Variablen erfolgt ebenfalls im Kopf des Klassenmoduls:<\/p>\n Für die übergabe der zu verwendenden Tabelle oder Abfrage stellt die Klasse mit folgender Property Let<\/b>-Prozedur eine Eigenschaft namens RecordsourceForm <\/b>zur Verfügung:<\/p>\n Schließlich weist die Prozedur das Recordset der Eigenschaft Recordset <\/b>des mit m_Form <\/b>referenzierten Hauptformulars zu. Damit wäre die Voraussetzung für die Transaktion geschaffen und das Hauptformular mit den entsprechenden Daten gefüllt.<\/p>\n Weitere Variablen<\/b><\/p>\n Damit die Klasse auch noch weiß, welche Datenherkunft sie für das Unterformular verwenden soll, deklarieren wir folgende Variable:<\/p>\n Diese füllen wir über die folgende Property Let<\/b>-Prozedur:<\/p>\n Außerdem benötigen wir noch zwei Variablen, mit denen wir den Namen des Primärschlüsselfeldes der Datenherkunft des Hauptformulars und den Namen des Fremdschlüsselwertes des Unterformulars speichern:<\/p>\n Auch diese können wir vom instanzierenden Formular aus per Eigenschaft übergeben. Dabei unterstützen uns die folgenden Property Let<\/b>-Prozeduren:<\/p>\n Schauplatzwechsel<\/b><\/p>\n Bevor wir in die eigentlichen Funktionen der Klasse einsteigen, schauen wir uns die Ereignisprozedur an, die durch das Ereignis Beim Laden <\/b>des Hauptformulars ausgelöst wird. Zunächst erhält das Klassenmodul des Hauptformulars frmBestellungenUndoKlasse <\/b>eine Variable, welche die Klasse clsUndo <\/b>referenziert:<\/p>\n Dann schauen wir uns die Prozedur Form_Load <\/b>an (s. Listing 3). Diese instanziert zunächst die Klasse clsUndo <\/b>und speichert den Verweis auf die neue Instanz in der Variablen objUndo<\/b>.<\/p>\n Listing 3: Diese Prozedur instanziert die Klasse clsUndo und übergibt die notwendigen Verweise.<\/span><\/b><\/p>\n Dann übergibt sie die Informationen über die beiden Formulare, die beiden Schaltflächen sowie den Namen der Datenherkünfte für das Haupt- und das Unterformular und die Namen des Primärschlüsselfeldes der Datenherkunft des Hauptformulars und des Fremdschlüsselfeldes der Datenherkunft des Unterformulars.<\/p>\n Interessante Zustände<\/b><\/p>\n Im Rahmen der nachfolgend beschriebenen Ereignisprozeduren, welche auf verschiedene Ereignisse im Haupt- und Unterformular reagieren, gibt es einige Zustände, die wir auf jeden Fall in Variablen speichern müssen, um diese zu bestimmten Gelegenheiten abzufragen:<\/p>\n Die drei Eigenschaften werden wie folgt deklariert:<\/p>\n Zur Eigenschaft bolDirtyForm <\/b>ist noch zu erwähnen, dass man prinzipiell über die Eigenschaft Dirty <\/b>eines Formulars prüft, ob der aktuelle Datensatz seit dem letzten Speichern geändert wurde. Gleiches gilt für das Unterformular. Allerdings wollen wir ja formularübergreifend feststellen, ob Daten geändert wurden.<\/p>\n Wenn der Benutzer im Hauptformular einen neuen Datensatz anlegt, wird Dirty <\/b>auf True <\/b>eingestellt. Wenn er dann zum Unterformular wechselt, ist der Datensatz im Hauptformular aber bereits wieder gespeichert.<\/p>\n Wenn wir also vom Start einer Transaktion bis zum CommitTrans <\/b>oder Rollback <\/b>speichern wollen, ob die Daten eines Formulars geändert wurden, benötigen wir diese Variable namens bolDirtyForm<\/b>.<\/p>\n Anzeigen eines neuen Datensatzes im Hauptformular<\/b><\/p>\n Bevor wir überhaupt mit dem ändern von Daten beginnen und die damit verbundenen Transaktionen starten, ausführen oder verwerfen können, müssen wir beim Anzeigen eines Datensatzes im Hauptformular die entsprechenden Daten im Unterformular nachreichen. Dies erledigen wir in der Prozedur, die durch das Ereignis Beim Anzeigen <\/b>des Hauptformulars ausgelöst wird.<\/p>\n Diese Prozedur sieht wie in Listing 4 aus und erledigt zunächst einige Dinge mehr als benötigt. Wichtig ist an dieser Stelle, dass die hinteren Anweisungen das Recordset für das Unterformular zusammenstellen – und zwar in der Regel so, dass es alle Datensätze der in m_RecordsourceSubform <\/b>angegebenen Abfrage oder Tabelle liefert, deren in m_FKSubform <\/b>gespeichertes Fremdschlüsselfeld den Wert des Primärschlüsselfeldes des Hauptformulars aus m_PKForm <\/b>enthält. Es kann natürlich auch geschehen, dass das Hauptformular einen neuen, leeren Datensatz anzeigt – dann soll auch das Unterformular eine leere Datenherkunft erhalten (das Kriterium 1=2 <\/b>liefert eine leere Datensatzgruppe).<\/p>\n Listing 4: Diese Ereignisprozedur wird beim Wechsel des Datensatzes im Haupformular ausgelöst.<\/span><\/b><\/p>\n Die übrigen Anweisungen erläutern wir weiter unten.<\/p>\n Starten einer Transaktion<\/b><\/p>\n Eine Transaktion soll in den folgenden Fällen gestartet werden:<\/p>\n Was geschieht, wenn der Benutzer im Haupt- oder Unterformular zu einem neuen Datensatz wechselt Dies ändert noch nichts an den Daten – der Datensatzzeiger wird lediglich auf einem neuen, leeren Datensatz positioniert.<\/p>\n Das tatsächliche Anlegen des Datensatzes beginnt erst, wenn der Benutzer den Inhalt eines der Felder der beteiligten Datenherkünfte ändert.<\/p>\n Die ersten genannten Aktionen lösen das Ereignis m_Form_Dirty <\/b>des Hauptformulars beziehungsweise das Ereignis m_Subform_Dirty <\/b>des Unterformulars aus.<\/p>\n Schauen wir uns zunächst das Ereignis für das Hauptformular an, das Sie in folgendem Listing finden:<\/p>\n![\"Haupt-](\"..\/fileadmin\/_temp_\/2013_06\/pic_912_002.png\")
<\/p>\nPrivate Sub <\/span>cmdOK_Click()\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>cmdVerwerfen_Click()\r\n Me.Undo\r\nEnd Sub<\/span><\/pre>\n\n
\n
![\"Die](\"..\/fileadmin\/_temp_\/2013_06\/pic_912_003.png\")
<\/p>\nPrivate <\/span>WithEvents m_Form As <\/span>Form\r\nPrivate <\/span>WithEvents m_Subform As <\/span>Form\r\nPrivate <\/span>WithEvents m_OKButton As <\/span> CommandButton\r\nPrivate <\/span>WithEvents m_CancelButton As <\/span> CommandButton<\/pre>\n![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2013_06\/pic_912_004.png\")
<\/p>\n\n
Public Property Set<\/span> <\/span>OKButton(cmd As <\/span> CommandButton)\r\n Set<\/span> m_OKButton = cmd\r\n With<\/span> m_OKButton\r\n .OnClick = \"[Event Procedure]\"\r\n End With<\/span>\r\nEnd Property<\/span><\/pre>\nPublic Property Set<\/span> <\/span>CancelButton(cmd As <\/span>CommandButton)\r\n Set<\/span> m_CancelButton = cmd\r\n With<\/span> m_CancelButton\r\n .OnClick = \"[Event Procedure]\"\r\n End With<\/span>\r\nEnd Property<\/span><\/pre>\nPublic Property Set<\/span> <\/span>Subform(frm As <\/span>Form)\r\n Set<\/span> m_Subform = frm\r\n With<\/span> m_Subform\r\n .AfterDelConfirm = \"[Event Procedure]\"\r\n .AfterUpdate = \"[Event Procedure]\"\r\n .BeforeDelConfirm = \"[Event Procedure]\"\r\n .OnDelete = \"[Event Procedure]\"\r\n .OnDirty = \"[Event Procedure]\"\r\n .OnError = \"[Event Procedure]\"\r\n .OnOpen = \"[Event Procedure]\"\r\n .OnUndo = \"[Event Procedure]\"\r\n End With<\/span>\r\nEnd Property<\/span><\/pre>\nPublic Property Set<\/span> <\/span>Form(frm As <\/span>Form)\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Set<\/span> m_Form = frm\r\n With<\/span> m_Form\r\n .AfterUpdate = \"[Event Procedure]\"\r\n .BeforeDelConfirm = \"[Event Procedure]\"\r\n .OnCurrent = \"[Event Procedure]\"\r\n .OnDelete = \"[Event Procedure]\"\r\n .OnDirty = \"[Event Procedure]\"\r\n .OnError = \"[Event Procedure]\"\r\n .OnOpen = \"[Event Procedure]\"\r\n .OnUnload = \"[Event Procedure]\"\r\n .OnUndo = \"[Event Procedure]\"\r\n End With<\/span>\r\n ''Aus Form_Open\r\n Set<\/span> db = DBEngine(0)(0)\r\n Set<\/span> wrk = DBEngine.Workspaces(0)\r\n Set<\/span> rst = db.OpenRecordset(m_RecordsourceForm, dbOpenDynaset)\r\n Set<\/span> m_Form.Recordset = rst\r\nEnd Property<\/span><\/pre>\nDim <\/span>db As <\/span>DAO.Database<\/pre>\nDim <\/span>wrk As <\/span>DAO.Workspace<\/pre>\nPrivate <\/span>m_RecordsourceForm As String<\/span><\/pre>\nPublic Property Let <\/span>RecordsourceForm( str As String<\/span>)\r\n m_RecordsourceForm = str\r\nEnd Property<\/span><\/pre>\nPrivate <\/span>m_RecordsourceSubform As String<\/span><\/pre>\nPublic Property Let <\/span>RecordsourceSubform (str As String<\/span>)\r\n m_RecordsourceSubform = str\r\nEnd Property<\/span><\/pre>\nPrivate <\/span>m_PKForm As String<\/span>\r\nPrivate <\/span>m_FKSubform As String<\/span><\/pre>\nPublic Property Let <\/span>PKForm(str As <\/span> String)\r\n m_PKForm = str\r\nEnd Property<\/span>\r\nPublic Property Let <\/span>FKSubform(str As <\/span> String)\r\n m_FKSubform = str\r\nEnd Property<\/span><\/pre>\nDim <\/span>objUndo As <\/span>clsUndo<\/pre>\nPrivate Sub <\/span>Form_Load()\r\n Set<\/span> objUndo = New<\/span> clsUndo\r\n With<\/span> objUndo\r\n Set<\/span> objUndo = New<\/span> clsUndo\r\n With<\/span> objUndo\r\n .RecordsourceForm = \"tblBestellungen\"\r\n .RecordsourceSubform = \"tblBestelldetails\"\r\n .PKForm = \"BestellungID\"\r\n .FKSubform = \"BestellungID\"\r\n Set<\/span> .Subform = Me!sfm.Form\r\n Set<\/span> .Form = Me\r\n Set<\/span> .OKButton = Me!cmdOK\r\n Set<\/span> .CancelButton = Me!cmdVerwerfen\r\n End With<\/span>\r\n End With<\/span>\r\nEnd Sub<\/span><\/pre>\n\n
Dim <\/span>bolDirtyForm As Boolean<\/span>\r\nDim <\/span>bolSavedForm As Boolean<\/span>\r\nDim <\/span>bolDeletedForm As Boolean<\/span><\/pre>\nPrivate Sub <\/span>m_Form_Current()\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n ...\r\n If <\/span>Not<\/span> m_Form.NewRecord Then<\/span>\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM \" & m_RecordsourceSubform _\r\n & \" WHERE \" & m_FKSubform & \" = \" _\r\n & Nz(m_Form.Recordset.Fields(m_PKForm), 0), dbOpenDynaset)\r\n Else<\/span>\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM \" & m_RecordsourceSubform & \" WHERE 1=2\", dbOpenDynaset)\r\n End If<\/span>\r\n Set<\/span> m_Subform.Recordset = rst\r\nEnd Sub<\/span><\/pre>\n\n
Private Sub <\/span>m_Form_Dirty(Cancel As <\/span> Integer)\r\n If <\/span>bolDirtyForm = False<\/span> Then<\/span>\r\n bolDirtyForm =