<\/p>\n
Wenn man Daten in die Tabellen einer 1:n-Beziehung eingeben möchte, nutzt man in der Regel ein Haupt- und ein Unterformular. Das Hauptformular nimmt die Daten der Mastertabelle auf, das Unterformular die Daten der Detailtabelle. Wenn man nun keine weiteren Vorsichtsmaßnahmen trifft, kann der Benutzer Daten in das Unterformular eingeben, ohne dass das Hauptformular einen Datensatz anzeigt. Damit erzeugt er Datensätze in der Detailtabelle, die mit keinem Datensatz der Mastertabelle verknüpft sind. Das ist aus mehreren Gründen schlecht – diese schauen wir uns an und zeigen, wie wir das Problem beheben können.<\/b><\/p>\nBeispieldatenbank<\/h2>\n
Wir wählen als einfaches Beispiel zwei Tabellen namens tblKategorien <\/b>und tblProdukte<\/b>. Die Tabelle tblProdukte <\/b>ist über das als Nachschlagefeld ausgelegte Fremdschlüsselfeld KategorieID <\/b>mit der Tabelle tblKategorien <\/b>verknüpft, sodass wir für jedes Produkt eine Kategorie auswählen können. Im Datenmodell sehen die beiden Tabellen mit ihrer Verknüpfung wie in Bild 1 aus.<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_001.png\")
<\/p>\n
Bild 1: Die Tabellen der Beispielanwendung<\/span><\/b><\/p>\n Der Eigenschaft Datensatzquelle <\/b>des Unterformulars sfmKategorienProdukte <\/b>weisen wir die Tabelle tblProdukte <\/b>hinzu. Aus der Feldliste ziehen wir alle Felder in den Detailbereich des Formularentwurfs und stellen die Eigenschaft Standardansicht <\/b>auf Datenblatt <\/b>ein (siehe Bild 2). Danach speichern und schließen wir dieses Formular.<\/p>\n Bild 2: Das Unterformular der Anwendung<\/span><\/b><\/p>\n Für das Hauptformular frmKategorienProdukte <\/b>legen wir die Tabelle tblKategorien <\/b>als Datensatzquelle fest. Auch hier ziehen wir alle Felder aus der Feldliste in den Detailbereich. Außerdem ziehen wir das Formular sfmKategorienProdukte <\/b>aus dem Navigationsbereich in das Hauptformular frmKategorienProdukte <\/b>und platzieren es unterhalb der hinzugefügten Felder. Access erkennt dabei automatisch die Beziehung zwischen den Tabellen, die als Datensatzquelle für die beiden Formulare dienen, und trägt die Verknüpfungsfelder, also das Fremdschlüsselfeld der Tabelle tblProdukte <\/b>und das Primärschlüsselfeld der Tabelle tblKategorien<\/b>, in die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformular-Steuerelements ein (siehe Bild 3).<\/p>\n Bild 3: Einbau des Unterformulars in das Hauptformular<\/span><\/b><\/p>\n Geht man in diesem Formular den üblichen Weg und legt zunächst eine Kategorie an, bevor man ein Produkt hinzufügt, werden die Daten miteinander verknüpft und das Fremdschlüsselfeld KategorieID <\/b>der Tabelle tblProdukte <\/b>weist den gewünschten Wert der Tabelle tblKategorien <\/b>auf. Das ist deswegen der Fall, weil das Fremdschlüsselfeld KategorieID <\/b>im Unterformular automatisch mit dem Wert des Primärschlüsselfeldes im Hauptformular als Standardwert gefüllt wird (siehe Bild 4).<\/p>\n Bild 4: Eingabe von Daten auf dem geplanten Weg<\/span><\/b><\/p>\n Das ist insbesondere deshalb möglich, weil durch den Wechsel ins Unterformular der Datensatz im Hauptformular gespeichert wird und der Primärschlüsselwert der Kategorie bereits verfügbar ist.<\/p>\n Wir können in diesem Formular allerdings auch direkt einen Datensatz im Unterformular anlegen, ohne dass das Hauptformular einen Datensatz anzeigt – beziehungsweise während es einen neuen, leeren Datensatz anzeigt, für den es noch keinen automatisch vergebenen Primärschlüsselwert gibt. Wechseln wir ins Unterformular, ist das Fremdschlüsselfeld KategorieID<\/b> noch nicht gefüllt (siehe Bild 5).<\/p>\n Bild 5: Ohne Kategorie wird auch das Fremdschlüsselfeld nicht vorbelegt<\/span><\/b><\/p>\n Wir können hier nun einen Datensatz anlegen, den wir Produkt 2 <\/b>nennen. Fällt uns dann auf, dass wir noch die Kategorie anlegen wollten und wechseln wir dazu ins Hauptformular, ist der Datensatz im Unterformular noch sichtbar.<\/p>\n Sobald wir jedoch mit der Eingabe in die Felder des Hauptdatensatzes beginnen, wird das Primärschlüsselfeld gefüllt und somit passt der Datensatz im Unterformular nicht mehr zu diesem Datensatz – er hat den Wert Null <\/b>im Fremdschlüsselfeld KategorieID<\/b>, während das Primärschlüsselfeld KategorieID <\/b>im Hauptformular nun den Wert 2 <\/b>aufweist (siehe Bild 6). Speichern wir nun den Datensatz im Hauptformular, indem wir auf den Datensatzmarkierer klicken oder zum Unterformular wechseln, wird der Standardwert für das dortige Fremdschlüsselfeld KategorieID<\/b> korrekt auf 2 <\/b>eingestellt. Der dort angelegte Produkt-Datensatz bleibt jedoch verschwunden (siehe Bild 7).<\/p>\n Bild 6: Nach dem Speichern im Hauptformular wird der Fremdschlüsselwert im Unterformular wieder auf den richtigen Wert eingestellt.<\/span><\/b><\/p>\n Bild 7: Nach dem Ergänzen der Kategorie verschwindet der Datensatz im Unterformular.<\/span><\/b><\/p>\n Werfen wir einen Blick in die Tabelle tblProdukte<\/b>, finden wir den verlorengeglaubten Datensatz allerdings wieder – er hat lediglich keinen Wert im Feld KategorieID<\/b>, weshalb er im Formular nicht im Kontext einer Kategorie erscheint (siehe Bild 8).<\/p>\n Bild 8: Der Produkt-Datensatz wurde angelegt – wenn auch ohne Kategorie.<\/span><\/b><\/p>\n Der Datensatz erscheint erst wieder, wenn wir im Formular zu einer neuen, leeren Kategorie wechseln – dann passt der Fremdschlüsselwert Null <\/b>wieder zu dem Primärschlüsselwert im Hauptformular, der für einen neuen, leeren Datensatz ebenfalls Null <\/b>lautet. Den falsch erstellten Datensatz können wir nun löschen oder wir weisen ihm über das Nachschlagefeld in der Tabelle eine Kategorie zu.<\/p>\n Es gibt viele Wege, mit denen wir verhindern können, dass ein Datensatz im Unterformular angelegt wird, wenn das Hauptformular noch keinen Datensatz enthält.<\/p>\n Ein Weg ist, die Eigenschaft Eingabe erforderlich <\/b>des Feldes KategorieID <\/b>der Tabelle tblProdukte <\/b>auf Ja <\/b>einzustellen. Das erledigen wir wie in Bild 9 im Entwurf der Tabelle tblProdukte<\/b>.<\/p>\n [<\/p>\n Bild 9: Verhindern von Datensätzen ohne Fremdschlüsselwert<\/span><\/b><\/p>\n Nun speichern und schließen wir die Tabelle und öffnen das Formular frmKategorienProdukte <\/b>erneut. Hier wechseln wir nun wieder direkt ins Unterformular, während das Hauptformular einen neuen, leeren Datensatz anzeigt.<\/p>\n Sobald wir hier das erste Zeichen in eines der Felder eintippen und somit den Datensatz im Unterformular in den Bearbeitungszustand versetzen, erscheint die Meldung aus Bild 10.<\/p>\n Bild 10: Fehler beim Anlegen eines Produkt-Datensatzes ohne erforderlichen Wert im Feld KategorieID<\/span><\/b><\/p>\n Wir können dieser Meldung zwar nun folgen und einen Eintrag im Feld KategorieID <\/b>auswählen. Aber erstens zeigen wir diese Feld hier nur an, um zu sehen, wann und ob die Beziehung über das Fremdschlüsselfeld hergestellt wird und zweitens wollen wir dem Benutzer nicht eine solche Meldung präsentieren.<\/p>\n Wir könnten an dieser Stelle noch weitergehen und diesen Fehler abfangen. Das ginge über das Ereignis Bei Fehler <\/b>des Unterformulars, wo wir prüfen können, welcher Fehler aufgetreten ist und diesen Fehler entsprechend behandeln. Allerdings ist dieser Weg relativ aufwendig, daher schauen wir uns eine einfachere Alternative an.<\/p>\n Dabei wollen wir verhindern, dass der Benutzer überhaupt auf das Unterformular zugreifen kann, wenn das Hauptformular noch keinen Datensatz aufweist. Das können wir mit einer sehr einfachen Maßnahme erreichen.<\/p>\n Dazu hinterlegen wir eine Ereignisprozedur für die Ereigniseigenschaft Beim Hingehen <\/b>des Unterformular-Steuerelements (nicht des Unterformulars selbst). Hier wählen wir den Wert [Ereignisprozedur] <\/b>aus und klicken auf die Schaltfläche mit den drei Punkten (siehe Bild 11).<\/p>\n Bild 11: Anlegen einer Prozedur, die beim Hingehen zum Unterformular ausgelöst wird<\/span><\/b><\/p>\n Die nun im VBA-Editor angelegte Ereignisprozedur füllen wir mit den Zeilen aus Bild 12. Diese prüft, ob das Feld KategorieID <\/b>des Hauptformulars Null <\/b>ist. Ist das der Fall, wurde im Hauptformular noch kein Datensatz angelegt. Dann soll die Anwendung eine Meldung anzeigen, die ihn darauf hinweist, dass er zunächst die Daten im Hauptformular ergänzen soll.<\/p>\n Bild 12: Prozedur, die beim Hingehen zum Unterformular ausgelöst wird.<\/span><\/b><\/p>\n Und damit der Fokus nicht doch noch auf einem Steuerelement im Unterformular landet, setzen wir diesen mit der SetFocus<\/b>-Methode auf das Steuerelement zur Eingabe des Kategorienamens.<\/p>\n Dies ist die einfachste Methode, um zu verhindern, dass der Benutzer Daten in das Unterformular eingibt, ohne dass ein Datensatz im Hauptformular existiert.<\/p>\n Eine alternative Methode ist es, das Unterformular-Steuerelement zu deaktivieren und es erst zu aktivieren, wenn im übergeordneten Formular ein Datensatz vorliegt. Wir haben dies einmal in einer Kopie des Hauptformulars namens frmKategorienProdukte_Enable <\/b>demonstriert. Diesem Formular haben wir für die Ereignisprozedur Beim Anzeigen<\/b>, die immer beim Anzeigen eines Datensatzes ausgelöst wird, die folgende Prozedur hinterlegt:<\/p>\n Dies sorgt dafür, dass das Unterformular-Steuerelement für einen neuen, leeren Datensatz zunächst deaktiviert wird und für alle anderen Datensätze aktiviert wird. Beachten Sie, dass wir explizit das Unterformular-Steuerelement deaktivieren, also das Steuerelement, indem das eigentliche Unterformular enthalten ist. Das dort enthaltene Unterformular können wir nicht deaktivieren. <\/p>\n Allerdings wird das Unterformular-Steuerelement nicht aktiviert, wenn der Benutzer mit der Bearbeitung eines Datensatzes begonnen hat – was eigentlich der Fall sein sollte, denn ab jetzt können wir theoretisch verknüpfte Datensätze im Unterformular hinzufügen.<\/p>\n Für das Aktivieren benötigen wir eine weitere Ereigniseigenschaft namens Bei Geändert<\/b>. Diese wird immer ausgelöst, wenn ein neuer, leerer Datensatz oder ein anderer, seit dem Anzeigen noch nicht bearbeiteter Datensatz, zum ersten Mal geändert wird. Das ist zum Beispiel beim Eingeben des ersten Zeichens in ein Textfeld der Fall. In der Formularansicht erkennt man an dem Stift-Symbol im Datensatzmarkierer (siehe Bild 13), dass dieses Ereignis ausgelöst wurde. Für die entsprechende Ereignisprozedur brauchen wir nur eine einzige Anweisung zu hinterlegen – diese aktiviert das Unterformular-Steuerelement:<\/p>\n Bild 13: Hier wurde soeben das Ereignis Bei Geändert ausgelöst.<\/span><\/b><\/p>\n Es gibt auch noch einen Fall, indem wir das Unterformular wieder deaktivieren müssen. Dieser tritt ein, wenn der Benutzer die Bearbeitung des neuen, leeren Datensatzes vor dem Speichern abbricht – in dem er zum Beispiel die Escape<\/b>-Taste drückt. Diese muss er dazu ein oder zwei Mal betätigen: Wenn er nur Daten in ein Steuerelement eingegeben hat, führt das einmalige Betätigen zum Verwerfen der Eingabe in das Steuerelement und zum Verlassen des Bearbeiten-Modus.<\/p>\n Hat er schon mehrere Steuerelemente bearbeitet, führt das erste Betätigen der Escape<\/b>-Taste zum Verwerfen der Änderung im aktuellen Steuerelement, das zweite zum Verwerfen aller übrigen Änderungen und zum Verlassen des Bearbeiten-Modus.<\/p>\n Diesen Modus können wir übrigens mit der Eigenschaft Dirty <\/b>des Formulars abrufen (Me.Dirty<\/b>). Diese liefert unmittelbar nach dem Verlassen der Ereignisprozedur Form_Dirty <\/b>den Wert True <\/b>und nach dem Verwerfen der Änderungen mit der Escape<\/b>-Taste wieder den Wert False<\/b>.<\/p>\n In der Form_Dirty<\/b>-Prozedur ist der Wert noch False<\/b>. Warum? Weil wir das Bearbeiten des Datensatzes in der Prozedur Form_Dirty <\/b>durch Setzen des Cancel<\/b>-Parameters noch abbrechen können.<\/p>\n Wie aber können wir das Unterformular wieder sperren, wenn der Benutzer die Escape<\/b>-Taste für einen neuen, bearbeiteten und ungespeicherten Datensatz betätigt? Dazu können wir theoretisch das Ereignis verwenden, das ausgelöst wird, wenn wir die Escape<\/b>-Taste betätigen. Dieses heißt Bei Rückgängig <\/b>und die Ereignisprozedur ist wie folgt aufgebaut:<\/p>\n Hier können wir nun allerdings nicht einfach die Anweisung zum Deaktivieren des Unterformular-Steuerelements einbauen. Es kann nämlich auch sein, dass der Benutzer einen bereits gespeicherten Datensatz ändert und die Änderungen mit Escape <\/b>verwirft. Dann soll das Unterformular-Steuerelement aktiviert bleiben, denn es existiert ja ein Datensatz im Hauptformular. Also probieren wir im ersten Ansatz Folgendes aus:<\/p>\n Hier prüfen wir, ob es eine KategorieID <\/b>gibt. Liegt eine vor, haben wir einen bestehenden Datensatz und können die Aktivierung beibehalten. Falls nicht, deaktivieren wir das Unterformular-Steuerelement wieder. Allerdings ist es beim Ereignis Form_Undo <\/b>wie bei Form_Dirty<\/b>: Es enthält einen Cancel<\/b>-Parameter und damit könnten wir das Verwerfen der Änderungen noch verhindern.<\/p>\n Die Änderung ist also in Form_Undo <\/b>noch nicht verworfen, sondern erst nach dem Beenden der Prozedur. Deshalb wird auch der beim Start der Bearbeitung hinzugefügte Wert für KategorieID <\/b>erst nach dem Ende von Form_Undo <\/b>wieder entfernt. Wir benötigen also einen Workaround.<\/p>\n Wir wissen, dass der Primärschlüsselwert eines neu hinzugefügten Datensatzes erst nach dem Ende von Form_Undo <\/b>wieder entfernt wird. Also brauchen wir eine Prozedur, die kurz nach dem Ende von Form_Undo <\/b>ausgelöst wird.<\/p>\n Standardmäßig gibt es diese aber nicht, sodass wir das Ereignis Bei Zeitgeber <\/b>nutzen. Wir starten den Zeitgeber am Ende von Form_Undo <\/b>und prüfen in der dadurch ausgelösten Prozedur, ob der Primärschlüsselwert leer ist.<\/p>\n Als Erstes setzen wir den Timer auf 50 Millisekunden – das sollte reichen:<\/p>\n Die dann auszuführende Prozedur Form_Timer <\/b>definieren wir wie folgt:<\/p>\n Als Erstes stellen wir die Eigenschaft TimerInterval <\/b>auf 0 <\/b>ein, damit die Prozedur Form_Timer <\/b>nicht direkt nochmal aufgerufen wird.<\/p>\n Danach prüfen wir, ob KategorieID <\/b>leer ist. Ist das der Fall, haben wir es wohl mit dem Verwerfen eines frisch angelegten Datensatzes zu tun und müssen das Unterformular-Steuerelement wieder deaktivieren. Das tun wir hier. Anderenfalls aktivieren wir es. <\/p>\n Dadurch, dass wir nur das Unterformular-Steuerelement deaktivieren, erhalten wir kein besonderes visuelles Feedback über die Deaktivierung. Wir erkennen dies nur am deaktivierten Bezeichnungsfeld. Um dem Benutzer vergebliche Versuche zu ersparen, das Unterformular zu verwenden, könnten wir die Sperrung noch ein wenig offensichtlicher machen. Das ist allerdings nicht ganz trivial, zumindest wenn das Unterformular in der Datenblattansicht angezeigt wird. Wir können dann zwar auch die Spalten der Datenblattansicht deaktivieren, aber dies wirkt sich nicht auf die Darstellung aus.<\/p>\n Wir können jedoch den Text des Bezeichnungsfeldes des Unterformular-Steuerelements anpassen, das wir zunächst mit lblUnterformular <\/b>bezeichnen. Außerdem machen wir es so breit, dass auch längere Texte angezeigt werden können.<\/p>\n An allen Stellen im bisher vorgestellten Code, wo wir das Unterformular-Steuerelement deaktivieren, fügen wir nun wie in Listing 1 die Zuweisung des Textes Produkte (Eingabe erst nach Angabe oder Auswahl einer Kategorie möglich): <\/b>ein. An allen Stellen, wo das Unterformular aktiviert wird, stellen wir es auf den einfachen Text Produkte: <\/b>ein. Damit erhalten wir immer einen passenden Text, an dem sich der Benutzer orientieren kann (siehe Bild 14).<\/p>\n![\"Das](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_002.png\")
<\/p>\n![\"Einbau](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_003.png\")
<\/p>\nProblem: Produkte ohne Kategorie<\/h2>\n
![\"Eingabe](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_004.png\")
<\/p>\n![\"Ohne](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_005.png\")
<\/p>\n![\"Nach](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_007.png\")
<\/p>\n![\"Nach](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_006.png\")
<\/p>\n![\"Der](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_008.png\")
<\/p>\nAnlegen von Datensätzen im Unterformular ohne Datensatz im Hauptformular verhindern<\/h2>\n
![\"Verhindern](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_011.png\")
<\/p>\n![\"Fehler](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_010.png\")
<\/p>\nZugriff auf das Unterformular ohne Datensatz im Hauptformular verwehren<\/h2>\n
![\"Anlegen](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_009.png\")
<\/p>\n![\"Prozedur,](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_012.png\")
<\/p>\nAlternative: Unterformular deaktivieren, wenn Hauptformular ohne Datensatz<\/h2>\n
Private Sub <\/span>Form_Current()\r\n If <\/span>IsNull(Me!KategorieID) Then<\/span>\r\n Me!sfmKategorienProdukte.Enabled = False<\/span>\r\n Else<\/span>\r\n Me!sfmKategorienProdukte.Enabled = True<\/span>\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\n![\"Hier](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_013.png\")
<\/p>\nPrivate Sub <\/span>Form_Dirty(Cancel As Integer<\/span>)\r\n Me!sfmKategorienProdukte.Enabled = True<\/span>\r\nEnd Sub<\/span><\/pre>\nUnterformular wieder deaktivieren<\/h2>\n
Private Sub <\/span>Form_Undo(Cancel As Integer<\/span>)\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>Form_Undo(Cancel As Integer<\/span>)\r\n If <\/span>IsNull(Me!KategorieID) Then<\/span>\r\n Me!sfmKategorienProdukte.Enabled = False<\/span>\r\n Else<\/span>\r\n Me!sfmKategorienProdukte.Enabled = True<\/span>\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nZeitliche Steuerung zum Deaktivieren des Unterformular-Steuerelements<\/h2>\n
Private Sub <\/span>Form_Undo(Cancel As Integer<\/span>)\r\n Me.TimerInterval = 50\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>Form_Timer()\r\n Me.TimerInterval = 0\r\n If <\/span>IsNull(Me!KategorieID) Then<\/span>\r\n Me!sfmKategorienProdukte.Enabled = False<\/span>\r\n Else<\/span>\r\n Me!sfmKategorienProdukte.Enabled = True<\/span>\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nDeaktivierung des Unterformulars optisch hervorheben<\/h2>\n
![\"Anzeige](\"..\/fileadmin\/_temp_\/2023_06\/pic_1463_014.png\")
<\/p>\n