<\/p>\n
André Minhorst, Duisburg<\/b><\/p>\n
Unterformulare werden meist in Zusammenhang mit der Darstellung von 1:n- oder m:n-Beziehungen verwendet. Dabei sind allzu schnell mit dem Unterformular Datensätze in die Detailtabelle geschrieben, obwohl es gar keinen Masterdatensatz gibt – und der Benutzer darf sich entweder mit den Access-Fehlermeldungen herumschlagen oder Inkonsistenzen in Kauf nehmen. Allein die Festlegung referentieller Integrität reicht hier nicht aus, um eine fehlerfreie Dateneingabe zu gewährleisten; dazu sind einige zusätzliche Handgriffe erforderlich.<\/b><\/p>\n
Damit Sie die im folgenden Kapitel beschriebenen Hintergründe nachvollziehen können, legen Sie am besten zuvor das Beispielformular an – Sie müssen dazu nur zwei Tabellen der Nordwind-Datenbank importieren und mit einem Assistenten eine Kombination aus Haupt- und Unterformular erstellen.<\/p>\n
![](\"..\/fileadmin\/_temp_\/{B2A2851D-4381-466C-930B-46CF7420CAE8}\/pic001.png\")
<\/p>\n
<\/b><\/p>\n
Bild 1: Kategorien und Artikel in Haupt- und Unterformular<\/span><\/b><\/p>\n Das Beispielformular enthält die beiden Tabellen Artikel und Kategorien der Nordwind-Datenbank. Das Formular erstellen Sie ausnahmsweise mit dem Assistenten:<\/p>\n Der Assistent legt nun ein Formular namens Kategorien mit einem Unterformular an, das er unter dem Namen Artikel Unterformular speichert und direkt anzeigt (siehe Bild 1). Das Formular lässt sich optisch sicher noch verbessern, reicht aber für unseren Zweck völlig aus.<\/p>\n Dieses Formular verwenden Sie hier stellvertretend für alle Formulare, die dem Anzeigen und Bearbeiten von 1:n- oder m:n-Beziehungen dienen. Die nachfolgend beschriebenen Probleme treten in beiden Varianten auf.<\/p>\n Die Verwendung von Unterformularen als Steuerelement in Formularen dient in den meisten Fällen der Anzeige und Bearbeitung von Daten aus zwei miteinander verknüpften Tabellen. Dabei treten zwei Fälle auf:<\/p>\n In beiden Fällen sind einige Regeln für die Dateneingabe zu beachten. So ist es beispielsweise mit dem üblicherweise unter Access als Primärindex verwendeten Autowert nicht möglich, Daten in eine Detailtabelle einzutragen, wenn in der Mastertabelle kein entsprechender Datensatz vorliegt. Das funktioniert nur in dem Fall, dass für die Beziehung zwischen den beiden Tabellen keine referentielle Integrität festgelegt ist.<\/p>\n Der Verzicht auf Festlegung dieser Eigenschaft ist aber nur in wenigen Fällen akzeptabel, in allen anderen heißt es: Wo keine referentielle Integrität festgelegt ist, herrschen bald Redundanzen und Inkonsistenz.<\/p>\n Wenn Sie aber nun vernünftigerweise referentielle Integrität zwischen den betroffenen Tabellen festgelegt haben (außer natürlich, Sie haben einen guten Grund, davon abzusehen), können bei der Eingabe für den Benutzer unangenehme Probleme auftauchen – und zwar immer, wenn man Daten im Unterformular einträgt, ohne dass zuvor ein Datensatz im Hauptformular angelegt wurde. Einen Unterschied gibt es dabei in Abhängigkeit davon, ob Sie für das Fremdschlüsselfeld der Datenherkunft des Unterformulars Nullwerte zulassen oder nicht.<\/p>\n Gehen wir doch einmal die unterschiedlichen Konstellationen bei der Eingabe von Daten in einem Unterformular durch.<\/p>\n Dabei werden drei Fälle unterschieden:<\/p>\n Wenn Sie vor dem Anlegen von Datensätzen im Unterformular einen Datensatz im Hauptformular angelegt haben, können Sie anschließend beliebig viele Datensätze im Unterformular anlegen. Wenn die beiden Eigenschaften Verknüpfen von und Verknüpfen nach des Unterformularsteuerelements die Namen des Primärschlüsselfelds der Datenherkunft des Hauptformulars und des Fremdschlüsselfelds des Unterformulars enthalten, ist dieser Wert im Haupt- und Unterformular bereits voreingestellt.<\/p>\n Wichtig: Verknüpfen von und Verknüpfen nach sind keine Eigenschaften des Formulars, das Sie als Unterformular verwenden, sondern des Steuerelements, in dem Sie es platzieren!<\/p>\n <\/b><\/p>\n Bild 2: Access aktualisiert das Fremdschlüsselfeld des Unterformulars automatisch.<\/span><\/b><\/p>\n <\/b><\/p>\n Bild 3: Ein neuer Datensatz im Hauptformular<\/span><\/b><\/p>\n <\/b><\/p>\n Bild 4: Einfügen eines Detaildatensatzes ohne Bezug zur Mastertabelle<\/span><\/b><\/p>\n Dass die Voreinstellung funktioniert, können Sie schnell nachvollziehen: öffnen Sie einfach das Beispielformular und klicken Sie bei vorhandener Kategorie im Hauptformular auf die Schaltfläche für das Anlegen eines neuen Datensatzes im Unterformular. Sollte das Feld Kategorie des Unterformulars nicht direkt sichtbar sein, scrollen Sie einfach dorthin – das Feld enthält automatisch die im Hauptformular eingestellte Kategorie (siehe Bild 2).<\/p>\n Erst wenn Sie einen Datensatz im Unterformular anlegen, ohne dass das Hauptformular einen Masterdatensatz anzeigt, auf den sich der Datensatz im Unterformular bezieht, wird es kritisch:<\/p>\n Verwenden Sie einfach das Beispielformular, um diesen Fall nachzuvollziehen. Wechseln Sie im Hauptformular auf einen neuen Datensatz, aber geben Sie dort noch keine Daten ein – die Schaltfläche für das Springen zu einem neuen Datensatz ist nun deaktiviert (siehe Bild 3).<\/p>\n Wechseln Sie nun ins Unterformular und geben Sie dort Beispieldaten ein. Das funktioniert zunächst ohne sichtliche Probleme. Diese folgen aber schneller, als man denkt: Access speichert die eingegebenen Daten ohne Murren, ohne diese mit einem Datensatz des Hauptformulars zu verknüpfen. Abb. 4 veranschaulicht das: Der erste Datensatz im Unterformular enthält keine Kategorie und lässt sich dennoch speichern – anderenfalls hätte Access beim Wechsel zu einem neuen Datensatz eine Fehlermeldung angezeigt.<\/p>\n <\/p>\n Möglicherweise rufen Sie jetzt: „Halt! Hier ist doch referentielle Integrität festgelegt, Access darf den Datensatz doch gar nicht speichern!“ Aber Access handelt richtig – zumindest was die Umsetzung der referentiellen Integrität betrifft. Diese besagt nämlich (und das steht in den wenigsten Fachbüchern), dass die Festlegung referentieller Integrität für eine Beziehung zwischen zwei Tabellen dafür sorgt, dass das Fremdschlüsselfeld der Detailtabelle entweder einen der in der Mastertabelle enthaltenen Primärschlüsselwerte oder – und das ist der springende Punkt – einen Nullwert enthalten darf. Access hält sich an diese Regel, was mit obigem Beispiel belegt wäre.<\/p>\n Nun ließe sich in diesem Beispiel die Kategorie über das entsprechende Feld des Unterformulars durchaus noch auswählen, aber das ist ja nicht der Sinn der Sache: Normalerweise sind die Fremdschlüsselfelder in Unterformularen gar nicht sichtbar, da ihr Inhalt ja bereits im Hauptformular angezeigt wird (hier hat der ansonsten tüchtige Assistent es ein wenig zu gut gemeint).<\/p>\n Noch größer wird das Dilemma, wenn Sie einige Daten im Unterformular eingegeben haben und dann zum Hauptformular wechseln, um die Daten des Masterdatensatzes nachzutragen.<\/p>\n Mit der Eingabe des ersten Zeichens legt Access nämlich den Datensatz des Hauptformulars temporär an und vergibt dafür einen Primärschlüsselwert – was sich auf die bereits eingegebenen Daten im Unterformular verheerend auswirkt:<\/p>\n Die verschwinden nämlich einfach, weil der im Hauptformular angezeigte Primärschlüsselwert ja nun einen bestimmten Wert angenommen hat, der nicht mehr mit dem Wert des Fremdschlüsselfeldes der Datenherkunft des Unterformulars vereinbar ist – nämlich dem Nullwert.<\/p>\n Die zuvor eingegebenen Daten des Unterformulars sind somit über das Formular nicht mehr erreichbar und können nur noch direkt in der Tabelle geändert werden.<\/p>\n Wem bekannt ist, dass referentielle Integrität auch Nullwerte als Fremdschlüssel zulässt, baut vor: Bereits im Tabellenentwurf lässt sich festlegen, dass für ein Feld in jedem Fall ein Wert eingegeben werden muss. Nur führt das im vorliegenden Fall ebenfalls zu einem Problem, denn beim Anlegen eines Datensatzes im Unterformular ohne vorhandenen Masterdatensatz erscheint eine für normale Anwender vermutlich nicht nachvollziehbare Fehlermeldung (siehe Bild 5). Das gilt insbesondere, da ja normalerweise – im Gegensatz zu unserem Beispielformular – die Fremdschlüsselfelder, die als Verknüpfung zum Hauptformular dienen, nicht angezeigt werden und der Benutzer gar keinen Zugriff auf diese hat.<\/p>\n <\/b><\/p>\n Bild 5: Fehlermeldung bei nicht erlaubtem Nullwert<\/span><\/b><\/p>\n Die Lösung des Problems ist verhältnismäßig einfach: Bringen Sie den Benutzer einfach dazu, zunächst einen Datensatz im Hauptformular anzulegen und sich erst dann dem Unterformular zuzuwenden.<\/p>\n Dazu gibt es mehrere Möglichkeiten. In jedem Fall müssen Sie vor dem Anlegen von Daten im Unterformular prüfen, ob im Hauptformular bereits ein Datensatz und damit ein verwertbarer Primärschlüssel vorliegt.<\/p>\n Die erste Möglichkeit verwendet die Ereigniseigenschaft Beim Hingehen (englisch: On Enter), um vor dem Eintritt in das Unterformular das Vorhandensein eines Datensatzes im Hauptformular zu prüfen.<\/p>\n Die Prozedur aus Quellcode 1 sorgt dafür, dass ein Meldungsfenster erscheint, wenn sich noch kein Datensatz im Hauptformular befindet, und setzt anschließend den Fokus auf das Feld Kategoriename.<\/p>\n Quellcode 1<\/b><\/p>\n Quellcode 2<\/b><\/p>\n Auf diesem Wege ließe sich natürlich auch direkt eine Validierung einbauen, die beispielsweise Pflichtfelder überprüft. Dazu ändern Sie einfach die Prozedur aus Quellcode 1 entsprechend ab und fügen eine Abfrage der Inhalte der Pflichtfelder hinzu (s. Quellcode 2).<\/p>\n Die Prozedur prüft die beiden Felder Kategoriename und Beschreibung auf ihren Inhalt und gibt eine entsprechende Meldung mit der Bitte um Nachbesserung aus, wenn eines der Felder noch keinen Text enthält.<\/p>\n Es lassen sich selten alle möglichen Schritte des Benutzers vorhersehen, die zu Fehlern führen könnten. Meist hilft es, jemanden durch eine Anwendung oder auch nur ein Formular klicken zu lassen, der nicht an der Entwicklung beteiligt ist. Auf diesem Wege kommen beiläufig Eingaben zustande, die der Entwickler selbst nicht in Erwägung zieht. Beispiel gefällig<\/p>\n Das um die Prozedur aus Quellcode 2 erweiterte Beispielformular verhindert nun Eingaben im Unterformular ohne vorheriges Anlegen des Datensatzes im Hauptformular.<\/p>\n In einem Fall wirkt die Aufforderung, doch zunächst einen Datensatz im Hauptformular anzulegen, ein wenig deplatziert: Zeigen Sie eine der vorhandenen Kategorien der Beispieldatenbank im Hauptformular an und wechseln Sie dann ins Unterformular – soweit kein Problem.<\/p>\n Wenn Sie dann mit der entsprechenden Schaltfläche der Navigationsleiste des Hauptformulars einen neuen Datensatz darin anlegen möchten, erscheint direkt die Bitte um die Eingabe fehlender Daten im Hauptformular – was den Benutzer verwirren dürfte. Er hat noch gar nicht mit der Eingabe begonnen und schon gibt“s einen Rüffel<\/p>\n Der Grund ist, dass Access nach einem Datensatzwechsel in Formularen immer versucht, den Fokus wieder auf das Steuerelement zu legen, das vorher den Fokus hatte – in diesem Fall das Unterformular. <\/p>\n Der Fokus fällt jedoch vorher auf jeden Fall auf das Hauptformular zurück – und beim Versuch von Access, diesen wieder auf das Unterformular zu legen, erscheint dann die entsprechende Meldung.<\/p>\n Um dem Benutzer ein wenig mehr Komfort zu bieten und ihn nicht beim Wechsel zu einem neuen Datensatz mit Vorgaben zu ärgern, legen Sie eine neue Prozedur für die Ereigniseigenschaft Beim Anzeigen an, die den Fokus beim Anlegen eines neuen Datensatzes im Hauptformular an das Feld Kategoriename des Hauptformulars gibt (s. Quellcode 3).<\/p>\n Quellcode 3<\/b><\/p>\n Vielleicht möchten Sie dem Benutzer auch einfach die Wahl lassen, ob er zunächst Daten im Haupt- oder im Unterformular eingibt.<\/p>\n Vielleicht hat er es ja mal eilig und möchte den Datensatz des Hauptformulars erst später bearbeiten Auch das ist kein Problem, soweit Sie eine eventuell notwendige Validierung vor dem Wechsel zu einem anderen Datensatz oder dem Schließen des Formulars durchführen. Es muss jedoch auf jeden Fall ein Datensatz im Hauptformular angelegt werden, da die Daten des Unterformulars sich sonst – wie bereits oben beschrieben – zumindest aus Formularsicht in die ewigen Jagdgründe verabschieden.<\/p>\n Nun stellt sich die Frage, wie Sie das Hauptformular dazu bringen, ohne Eingabe von Daten einen Datensatz zu speichern. Die Vorgehensweise ist nicht ganz einfach; es reicht nicht aus, nur ein Requery, Refresh oder DoCmd.RunCommand acCmdSaveRecord abzusetzen.<\/p>\n Ein wenig experimentieren im Formular führt zu der Erkenntnis, dass Sie den Datensatz speichern können, sobald Sie den Inhalt auch nur eines der Datenfelder ändern. Das Formular zeigt dann als Datensatzmarkierer einen Bleistift an und fügt für neue Datensätze einen Wert für das Autowert-Feld ein (siehe Bild 6). Damit ist das Formular bereit zum Speichern dieses Datensatzes.<\/p>\n Auch wenn Sie die Felder durch Löschen der Inhalte wieder in den Ausgangszustand zurückversetzen, bleibt das Formular „schmutzig“ – der im Formular angezeigte Inhalt des Datensatzes stimmt nicht mehr mit dem in der Tabelle gespeicherten Datensatz überein. Dabei ist es unerheblich, ob der Datensatz überhaupt schon in der Tabelle gespeichert ist oder nicht.<\/p>\n <\/b><\/p>\n Bild 6: Bereitmachen zum Speichern!<\/span><\/b><\/p>\n Da Sie dem Benutzer die Möglichkeit geben möchten, Daten ins Unterformular einzugeben, ohne dass er vorher Daten im Hauptformular eingeben muss, nehmen Sie ihm nun die Aufgabe ab, manuell eine Eingabe im Hauptformular vorzunehmen und diese wieder rückgängig zu machen (das Speichern würde in diesem Fall automatisch durch den Wechsel zum Unterformular erledigt).<\/p>\n Das Anlegen und Löschen erfolgt durch die Prozedur aus Quellcode 4. Das Einfügen und Entfernen einer Eingabe simuliert die Prozedur, indem sie den Fokus auf ein Datenfeld des Hauptformulars und anschließend die Eigenschaft Dirty auf True setzt – und das alles auch nur, wenn das Hauptformular aktuell einen neuen Datensatz enthält.<\/p>\n Quellcode 4<\/b><\/p>\n Durch das Verlassen des Hauptformulars wird dessen Inhalt automatisch gespeichert und der neu erzeugte Autowert steht im Hauptformular als Primärschlüssel und im Unterformular als Inhalt des Fremdschlüsselfeldes bereit.<\/p>\n Eine weniger elegante Lösung ist das Erzwingen der Eingabe eines Wertes für das Fremdschlüsselfeld der Datenherkunft des Unterformulars. Im Beispiel würde dies bedeuten, dass Sie für das Feld Kategorie-Nr auf Tabellenentwurfs-Ebene festlegen, dass eine Eingabe zwingend erforderlich (siehe Bild 7).<\/p>\n <\/b><\/p>\n Bild 7: Erzwingen der Eingabe für ein Tabellenfeld<\/span><\/b><\/p>\n Damit schließen Sie zwar generell aus, dass Artikel-Datensätze mit einem Nullwert für das Feld Kategorie-Nr angelegt werden.<\/p>\n Die Behandlung des Problems im Formular\/Unterformular wird dadurch nicht vereinfacht. Basierend auf dem Beispielformular im Anfangszustand läuft die Dateneingabe nun folgendermaßen ab: <\/p>\n Sobald Sie Daten in eines der Felder im Unterformular eingeben, obwohl im Hauptformular kein Datensatz angelegt wurde, erscheint eine entsprechende Fehlermeldung (siehe Bild 5).<\/p>\n Die Fehlermeldung resultiert in dem Fall indirekt aus dem Fehlen eines Datensatzes im Hauptformular; wäre dieser vorhanden, hätte Access dessen Primärschlüssel in das Fremdschlüsselfeld der Datenherkunft des Unterformulars eingefügt.<\/p>\n Um den Benutzer nicht im Regen stehen zu lassen, fangen Sie diese Fehlermeldung ab und ersetzen sie durch eine ein wenig aussagekräftigere. Das erledigen Sie durch eine entsprechende Prozedur, die durch die Ereigniseigenschaft Bei Fehler des Unterformulars ausgelöst wird.<\/p>\n Die Prozedur (s. Quellcode 5) fragt zunächst die Fehlernummer ab. Wenn es sich – wie in unserem Falle – um die Fehlernummer 3314 handelt, zeigt die Prozedur ein Meldungsfenster an, macht die änderungen im Unterformular rückgängig und setzt den Fokus auf das Feld Kategoriename des Hauptformulars.<\/p>\n Quellcode 5<\/b><\/p>\n Eine einfache Aufgabe wie das Einfügen von Datensätzen in ein Formular mit Unterformular birgt durchaus Tücken. Im vorliegenden Beitrag haben Sie erfahren, wie Sie Problemen vorbeugen, die bei der Verwendung von verknüpften Haupt- und Unterformularen auftreten können, wenn der Benutzer sich allzu schnell um die Dateneingabe im Unterformular kümmert.<\/p>\n Welche der beiden alternativen Lösungsmöglichkeiten Sie einsetzen, hängt vom persönlichen Geschmack ab. Die Variante, den Benutzer direkt beim Eintreten in das Unterformular aufzuhalten, ist sicher eleganter, als erst die Eingabe eines Zeichens in einem der Datenfelder des Unterformulars zuzulassen. Dafür bietet die zweite Variante den Vorteil, dass Eingaben von Datensätzen in die Detailtabelle ohne Angabe eines Wertes für das Fremdschlüsselfeld schon auf Tabellenebene unterbunden werden.<\/p>\n","protected":false},"excerpt":{"rendered":" Unterformulare werden meist in Zusammenhang mit der Darstellung von 1:n- oder m:n-Beziehungen verwendet. Dabei sind allzu schnell mit dem Unterformular Datensätze in die Detailtabelle geschrieben, obwohl es gar keinen Masterdatensatz gibt – und der Benutzer darf sich entweder mit den Access-Fehlermeldungen herumschlagen oder Inkonsistenzen in Kauf nehmen. Allein die Festlegung refe-rentieller Integrität reicht hier nicht aus, um eine fehlerfreie Dateneingabe zu gewährleisten; dazu sind einige zusätzliche Handgriffe erforderlich.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[66012005,662005,44000023],"tags":[],"class_list":["post-55000261","post","type-post","status-publish","format-standard","hentry","category-66012005","category-662005","category-Mit_Formularen_arbeiten"],"yoast_head":"\nKeine Probleme mit Datensatz im Hauptformular<\/h2>\n
![](\"..\/fileadmin\/_temp_\/{B2A2851D-4381-466C-930B-46CF7420CAE8}\/pic002.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{B2A2851D-4381-466C-930B-46CF7420CAE8}\/pic003.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{B2A2851D-4381-466C-930B-46CF7420CAE8}\/pic004.png\")
<\/p>\nVorsicht: Nullwerte erlaubt!<\/h2>\n
Nullwerte verboten<\/h2>\n
![](\"..\/fileadmin\/_temp_\/{B2A2851D-4381-466C-930B-46CF7420CAE8}\/pic005.png\")
<\/p>\nHauptformular vor dem Eintritt ins Unterformular überprüfen<\/h3>\n
Private Sub Artikel_Unterformular_Enter()\r\n If Me.NewRecord Then\r\n MsgBox \"Bitte legen Sie zunächst einen \" _ & \"Datensatz im Hauptformular an.\"\r\n Me.Kategoriename.SetFocus\r\n Exit Sub\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub Artikel_Unterformular_Enter()\r\n If Nz(Me.Kategoriename, \"\") = \"\" Then\r\n MsgBox \"Bitte geben Sie einen \" _ & \"Kategorienamen ein.\"\r\n Me.Kategoriename.SetFocus\r\n Exit Sub\r\n End If\r\n If Nz(Me.Beschreibung, \"\") = \"\" Then\r\n MsgBox \"Bitte geben Sie eine Beschreibung ein.\"\r\n Me.Beschreibung.SetFocus\r\n Exit Sub\r\n End If\r\nEnd Sub<\/pre>\n
Neuer Masterdatensatz bei Fokus auf Unterformular<\/h3>\n
Private Sub Form_Current()\r\n If Me.NewRecord Then\r\n Me.Kategoriename.SetFocus\r\n End If\r\nEnd Sub<\/pre>\n
… oder doch erst im Unterformular<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{B2A2851D-4381-466C-930B-46CF7420CAE8}\/pic006.png\")
<\/p>\nPrivate Sub Artikel_Unterformular_Enter()\r\n If Me.NewRecord Then\r\n Me.Kategoriename.SetFocus\r\n Me.Dirty = True\r\n Me.Artikel_Unterformular.SetFocus\r\n End If\r\nEnd Sub<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{B2A2851D-4381-466C-930B-46CF7420CAE8}\/pic007.png\")
<\/p>\nPrivate Sub Form_Error(DataErr As _ Integer, Response As Integer)\r\n If DataErr = 3314 Then\r\n MsgBox \"Bitte legen Sie \" _ & \"zunächst einen Datensatz im \" _ & \"Hauptformular an.\"\r\n Response = acDataErrContinue\r\n Me.Undo\r\n Forms!Kategorien!Kategoriename. _ SetFocus\r\n End If\r\nEnd Sub<\/pre>\n