<\/p>\n
Meistens zeigt man 1:n-Beziehungen in einem Haupt- und einem Unterformular an. Was aber, wenn man die Datensätze beider Seiten im überblick anzeigen möchte – etwa wenn Sie alle Kategorien in einer Liste und die Artikel zur ausgewählten Kategorie in einer anderen Liste darzustellen Oder, um es noch eine Nummer komplizierter zu machen, im Hauptformular die Kunden, im ersten Unterformular ihre Bestellungen und im zweiten Unterformular die Bestellpositionen der im ersten Unterformular ausgewählten Bestellung Dann ist meist ein kleiner Trick erforderlich, um dies zu bewerkstelligen – wie der vorliegende Beitrag zeigt.<\/b><\/p>\n
Herkömmliche Darstellung<\/b><\/p>\n
Normalerweise verwendet man zur Darstellung von 1:n-Beziehungen ein Haupt- und ein Unterformular. Das Hauptformular zeigt dabei die Datensätze der Mastertabelle an, also beispielsweise die Daten der Tabelle tblKategorien<\/b>. Die Anzeige ist dabei allerdings auf Formularansicht eingestellt, was bewirkt, dass nur die Daten jeweils eines Datensatzes im Formular erscheinen.<\/p>\n
Das Unterformular zeigt die Daten der Detailtabelle an, also der Tabelle, die über ein Fremdschlüsselfeld mit den Datensätzen der Mastertabelle verknüpft ist. In unserem Beispiel handelt es sich dabei um die Tabelle tblArtikel<\/b>.<\/p>\n
Das Formular aus Bild 1 ist genau wie beschrieben aufgebaut – es zeigt die Daten der Tabelle tblKategorien <\/b>im Hauptformular und die der Tabelle tblArtikel <\/b>im Unterformular an. Damit das Unterformular nur die Daten der Tabelle tblArtikel <\/b>anzeigt, die über das Fremdschlüsselfeld KategorieID <\/b>mit dem aktuellen Datensatz der Tabelle tblKategorien <\/b>im Hauptformular verknüpft sind, trägt man für die Eigenschaft Verknüpfen von <\/b>des Unterformular-Steuerelements den Namen des Fremdschlüsselfeldes der Tabelle im Unterformular ein (hier KategorieID<\/b>) und für die Eigenschaft Verknüpfen nach <\/b>den Namen des Primärschlüsselfeldes der im Hauptformular abgebildeten Tabelle tblKategorien<\/b>. Das Ergebnis finden Sie in Bild 2 vor: Sie können durch die Datensätze im Hauptformular navigieren und das Unterformular zeigt jeweils nur die passenden Datensätze an.<\/p>\n
![\"1:n-Beziehung](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_001.png\")
<\/p>\n
Bild 1: 1:n-Beziehung in Haupt- und Unterformular mit Verknüpfungseigenschaften<\/span><\/b><\/p>\n Bild 2: 1:n-Beziehung in Haupt- und Unterformular<\/span><\/b><\/p>\n Zwei Unterformulare<\/b><\/p>\n Nun gehen wir eine Stufe weiter: Wir wollen die Kategorien nicht mehr im Hauptformular anzeigen, sondern in einem weiteren Unterformular. So hat der Benutzer nicht nur die mit einer Kategorie verknüpften Artikel im überblick, sondern kann auch gleich die Liste der Kategorien einsehen und die gewünschte Kategorie auswählen.<\/p>\n Um dies zu erreichen, legen Sie zunächst ein neues Hauptformular namens frmKategorienArtikelUFUF <\/b>an (UFUF <\/b>für Unterformular\/Unterformular). Dann erstellen Sie ein Formular namens sfmKategorienUFUF<\/b>, das die Tabelle tblKategorien <\/b>als Datenherkunft verwendet und seine Daten in der Datenblattansicht anzeigt. Auf ähnliche Weise erstellen Sie das Formular sfmArtikelUFUF<\/b>, das Sie mit der Tabelle tblArtikel <\/b>füllen – ebenfalls in der Datenblattansicht. Ziehen Sie beide Unterformulare in das Hauptformular. Da das Hauptformular seinerseits keine Daten anzeigen soll, entfernen Sie der übersichtlichkeit halber Elemente wie die Navigationsschaltflächen<\/b>, Bildlaufleisten <\/b>und Datensatzmarkierer<\/b>, indem Sie die entsprechenden Eigenschaften jeweils auf den Wert Nein <\/b>einstellen. Beide Formulare ziehen Sie nun nebeneinander in das Hauptformular frmKategorienArtikelUFUF<\/b>, sodass dieses wie in Bild 3 aussieht.<\/p>\n Bild 3: Zwei Unterformulare, die miteinander verknüpft werden sollen<\/span><\/b><\/p>\n Ein Wechsel in die Formularansicht zeigt, dass die Daten schon einmal wie gewünscht erscheinen (s. Bild 4). Allerdings filtert das rechte Unterformular seine Daten noch nicht nach dem aktuell im linken Unterformular angezeigten Wert.<\/p>\n Bild 4: Aktuell zeigen beide Formulare alle Daten an, aber die Artikel werden nicht nach der aktuellen Kategorie gefiltert.<\/span><\/b><\/p>\n Dummerweise erkennt Access auch nicht automatisch, was wir hier vorhaben, daher füllt es die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>nicht automatisch aus wie im vorherigen Beispiel. Kommen wir hier überhaupt mit den beiden Eigenschaften aus Ein Versuch, für die Eigenschaft Verknüpfen Nach <\/b>einen direkten Bezug zum anderen Unterformular unterzubringen wie in Bild 5, scheitert allerdings – Access fragt den Ausdruck Parent!sfmKategorienUFUF!KategorieID<\/b> in einer Inputbox ab und das Unterformular sfmArtikelUFUF <\/b>bleibt leer.<\/p>\n Bild 5: Diese Einstellung funktioniert nicht.<\/span><\/b><\/p>\n Allerdings sollte man immer mehrere Varianten ausprobieren und vor allem eventuelle Tipp- oder Syntaxfehler ausschließen. In diesem Fall war es kein Syntaxfehler, Access kann den zunächst verwendeten Ausdruck schlicht nicht verarbeiten. Mit dem folgenden Ausdruck für die Eigenschaft Verknüpfen nach <\/b>haben wir allerdings mehr Erfolg:<\/p>\n Das Unterformular sfmArtikelUFUF <\/b>zeigt nach dem Wechsel in die Entwurfsansicht die korrekten Daten an, also nur diejenigen Artikel, die zur aktuellen Kategorie gehören. Dummerweise ist die Begeisterung nach dem Wechsel zu einer anderen Kategorie schon wieder erledigt: Die zuvor angezeigten Artikel werden nicht gegen die der nun eingestellten Kategorie ausgetauscht.<\/p>\n Erst wenn man links eine neue Kategorie auswählt, dann in das rechte Unterformular klickt und dann mit der Taste F5 <\/b>die Datenherkunft aktualisiert, zeigt dieses Unterformular die gewünschten Artikel-Datensätze an. Das ist allerdings ein wenig umständlich.<\/p>\n Also kommen wir nicht umhin, mit einer kleinen VBA-Prozedur nachzuhelfen. Da das rechte Unterformular immer dann aktualisiert werden soll, wenn der Benutzer im linken Unterformular einen anderen Datensatz ausgewählt hat, benötigen wir eine Ereignisprozedur, die durch das Ereignis Beim Anzeigen <\/b>des linken Unterformulars ausgelöst wird.<\/p>\n Das wäre also vom linken Unterformular aus ein Verweis auf das Parent<\/b>-Objekt und von dort aus auf das Unterformular-Steuerelement sfmArtikelUFUF <\/b>und dann auf das darin enthaltene Form<\/b>-Objekt. Für dieses soll dann die Requery-Methode ausgeführt werden, was wie folgt aussehen könnte:<\/p>\n Access macht uns aber beim öffnen des Formulars mit der Fehlermeldung aus Bild 6 einen Strich durch die Rechnung.<\/p>\n Bild 6: Fehlermeldung beim öffnen des Formulars<\/span><\/b><\/p>\n In einem solchen Fall klickt man am besten auf die Debuggen<\/b>-Schaltfläche und untersucht die aktuelle Situation durch entsprechende Prüfungen im Direktfenster des VBA-Fensters. Möglicherweise haben wir ja irgendwo einen Syntaxfehler eingebaut<\/p>\n Also hangeln wir uns durch die referenzierten Elemente, wobei wir uns von links nach rechts vorarbeiten und am besten immer eine gängige Eigenschaft des jeweils referenzierten Elements abfragen. Wir starten mit dieser Abfrage:<\/p>\n <\/p>\n Dies klappt also. Gehen wir einen Schritt weiter:<\/p>\n Und noch einen Schritt:<\/p>\n Hier erscheint dann die bereits bekannte Fehlermeldung. Das im Unterformularsteuerelement enthaltene Formular ist also anscheinend nicht verfügbar. Das kann natürlich sein, denn die Unterformulare werden ja in einer bestimmten Reihenfolge geladen – möglicherweise ist das Unterformular sfmArtikelUFUF <\/b>ja noch gar nicht existent, wenn die obige Ereignisprozedur versucht, darauf zuzugreifen.<\/p>\n Wenn Sie an dieser Stelle auf die Schaltfläche Beenden <\/b>der Fehlermeldung klicken, erscheint das Formular mit beiden Unterformularen, wobei die Artikel entsprechend dem aktuell markierten ersten Eintrag des Kategorien-Unterformulars gefiltert werden – aber dies war ja auch schon ohne den Einsatz der Ereignisprozedur der Fall.<\/p>\n Wenn Sie nun allerdings eine andere Kategorie wählen, zeigt das rechte Unterformular plötzlich die zugeordneten Artikel an – die Ereignisprozedur scheint also doch korrekt zu funktionieren, nur eben nicht beim öffnen des Formulars.<\/p>\n Wir brauchen uns also nur darum zu kümmern, dass das Unterformular sfmArtikelUFUF <\/b>nur aktualisiert wird, wenn es bereits vorhanden ist. Da dies beim öffnen des Hauptformulars automatisch geschieht, können wir die Prüfung aus Listing 1 in die Ereignisprozedur einbauen.<\/p>\n Listing 1: Aktualisieren des Unterformulars sfmArtikelUFUF<\/span><\/b><\/p>\n Diese versucht, nach vorheriger Deaktivierung der Fehlerbehandlung den Namen des Unterformulars einzulesen. Ist das Formular bereits vorhanden, ist strForm <\/b>danach mit dem Namen des Formulars gefüllt. Dies prüft eine If…Then<\/b>-Bedingung und aktualisiert in diesem Fall die Datenherkunft des Unterformulars sfmArtikelUFUF<\/b>.<\/p>\n Elegantere Lösung<\/b><\/p>\n Nun ist dies nicht die schönste Lösung. Das eine Unterformular weiß nicht, wann das andere Unterformular geladen wird – das ist nicht optimal. Wir wollen zunächst einmal betrachten, in welcher Reihenfolge die Unterformulare eigentlich geladen werden – und wie diese Zeitpunkte sich zum Laden des Hauptformulars verhalten. Also fügen Sie sowohl für das Hauptformular als auch für die beiden Unterformulare jeweils eine Ereignisprozedur für das Ereignis Beim Laden <\/b>hinzu.<\/p>\n Wir benötigen keine weiteren Anweisungen, lediglich je einen Haltepunkt in der ersten Zeile der jeweiligen Prozedur. Wenn Sie das Formular nun öffnen, zeigt der VBA-Editor nacheinander die Haltepunkte in der entsprechenden Reihenfolge an. Wir stellen fest: Das Unterformular sfmKategorienUFUF <\/b>lädt als erstes, dann folgt sfmArtikelUFUF <\/b>und schließlich das Hauptformular.<\/p>\n Ein paar weitere Experimente, in denen wir die Unterformulare nacheinander ausschneiden und neu anlegen, zeigen, dass das Hauptformular immer zuletzt geladen wird.<\/p>\n Bei den Unterformularen richtet sich die Reihenfolge offensichtlich danach, in welcher Reihenfolge die Unterformulare zum Hauptformular hinzugefügt wurden.<\/p>\n Mit dieser Erkenntnis gehen wir das Ganze von ganz oben an, nämlich vom Hauptformular aus. Der designtechnische Hintergrund ist, dass das Hauptformular nämlich weiß, dass es die beiden Unterformulare enthält, umgekehrt aber nicht.<\/p>\n Wie aber wollen wir im Hauptformular erfahren, wann der Benutzer einen neuen Datensatz im Unterformular sfmKategorienUFUF <\/b>ausgewählt hat Ganz einfach: Indem wir im Klassenmodul des Hauptformulars ein Objekt deklarieren, mit dem wir dann das Unterformular referenzieren und dessen Ereignisse abfangen. Dazu deklarieren wir es mit dem Schlüsselwort WithEvents <\/b>im Kopf des Klassenmoduls des Formulars frmKategorienArtikelUFUF <\/b>als Form<\/b>-Objekt.<\/p>\n über die beiden Kombinationsfelder im Kopf des Code-Fensters können wir nun links das Objekt objSfmKategorien-UFUF <\/b>auswählen und rechts das Ereignis OnCurrent<\/b>. Dies legt im Klassenmodul die Ereignisprozedur objSfmKategorienUFUF_Current <\/b>an, die durch das Wechseln des Datensatzes im Unterformular sfmKategorienUFUF <\/b>ausgelöst wird.<\/p>\n Nun müssen wir allerdings noch die Objektvariable mit einem Verweis auf das betroffene Unterformular füllen. Dies erledigen wir in der Ereignisprozedur, die durch das Ereignis Beim Laden <\/b>des Hauptformulars ausgelöst wird. Dort stellen wir auch die Eigenschaft OnCurrent <\/b>des Objekts objSfmKategorienUFUF <\/b>auf den Wert [Event Procedure] <\/b>ein. Dies entspricht dem Einstellen der Eigenschaft Beim Anzeigen <\/b>auf den Wert [Ereigniseigenschaft]<\/b>.<\/p>\n Wenn Sie nun noch die Anweisung zum Aktualisieren des Unterformulars sfmArtikelUFUF <\/b>zur Prozedur objSfmKategorienUFUF_Current <\/b>hinzufügen, sind Sie fertig – der Code des Hauptformulars sieht nun wie in Listing 2 aus und aktualisiert den Inhalt des rechten Unterformulars, wenn der Benutzer im linken Unterformular einen neuen Datensatz auswählt.<\/p>\n Listing 2: Aktualisieren des Unterformulars sfmArtikelUFUF, alternativer Weg<\/span><\/b><\/p>\n Wichtiger Hinweis: Damit das Ereignis Beim Anzeigen <\/b>des Unterformulars sfm-KategorienUFUF <\/b>auch ausgelöst wird, müssen Sie dem Unterformular noch ein Klassenmodul hinzufügen. Das erledigen Sie, soweit noch nicht geschehen, wenn Sie die Eigenschaft Enthält Modul <\/b>auf den Wert Ja <\/b>einstellen (s. Bild 7).<\/p>\n Bild 7: Hinzufügen eines Klassenmoduls zu einem Formular<\/span><\/b><\/p>\n Einfachere Variante<\/b><\/p>\n Wer nicht so gern mit VBA programmiert, kann auch die folgende Variante verwenden. Dabei fügen wir dem Hauptformular ein Textfeld namens txtKategorieID <\/b>hinzu.<\/p>\n Dessen Steuerelementinhalt stellen wir auf das Feld KategorieID <\/b>des ersten Unterformulars ein, also auf den folgenden Ausdruck:<\/p>\n Damit zeigt dieses Textfeld, das im echten Betrieb natürlich ausgeblendet sein soll, immer die KategorieID <\/b>des im Unterformular sfmKategorienUFUF <\/b>ausgewählten Datensatzes an.<\/p>\n Und wie bringen wir nun das zweite Unterformular dazu, nur die Artikel anzuzeigen, die zu dieser Kategorie gehören Ganz einfach: Wir stellen einfach die Eigenschaft des entsprechenden Unterformular-Steuerelements auf den Namen dieses Textfeldes ein, also txtKategorieID<\/b> (s. Bild 8).<\/p>\n Bild 8: Verknüpfung über Umwege<\/span><\/b><\/p>\n Dann gelingt die Synchronisierung völlig automatisch und ohne Code, hat aber einen entscheidenden Nachteil: Es dauert manchmal ein paar Sekundenbruchteile, bis die Aktualisierung erfolgt.<\/p>\n Wenn man schnell durch die Datensätze navigiert, kann es daher schon mal haken. Dies liegt daran, dass das Unterformular nicht ständig den Wert des Textfeldes im Hauptformular abfragt. Aus Perfomance-Sicht sollte man also die erste Variante verwenden.<\/p>\n 1:n und 1:n<\/b><\/p>\n Es gibt noch eine weitere denkbare interessante Konstellation. Dabei zeigt das Hauptformular die Daten einer Tabelle an, das erste Unterformular alle Daten, die mit dem aktuellen Datensatz des Hauptformulars per 1:n-Beziehung verknüpft sind, und das zweite Unterformular zeigt alle Datensätze an, die mit dem aktuell markierten Datensatz im ersten Unterformular verknüpft sind.<\/p>\n Im Beispiel sollen dies die Tabellen tblKunden <\/b>(im Hauptformular), tblBestellungen <\/b>(im ersten Unterformular) und tblBestelldetails <\/b>(im zweiten Unterformular) sein. Dem Hauptformular, das frmKundenBestellungenArtikel <\/b>heißt, fügen wir einige repräsentante Felder der Tabelle tblKunden <\/b>hinzu, die Ansicht des Hauptformulars ist die Formularansicht.<\/p>\n Das erste Unterformular heißt sfmBestellungen <\/b>und soll die Felder Bestelldatum<\/b>, Lieferdatum<\/b>, Versanddatum <\/b>und VersandUeber <\/b>enthalten. Diese Felder werden in der Datenblattansicht angezeigt. Das zweite Unterformular heißt sfmBestelldetails <\/b>und liefert die Felder ArtikelID<\/b>, Einzelpreis<\/b>, Anzahl <\/b>und Rabatt <\/b>der Tabelle tblBestelldetails<\/b>. Auch dieses Formular zeigt seine Daten in der Datenblattansicht an (s. Bild 9).<\/p>\n Bild 9: Hauptformular mit zwei verknüpften Unterformularen<\/span><\/b><\/p>\n Wenn wir nun in die Formularansicht wechseln, funktionieren zumindest schon einmal das Hauptformular und das erste Unterformular wie gewohnt: Wenn Sie im Hauptformular einen Kunden auswählen, zeigt das Unterformular sfmBestellungen <\/b>die dazu gehörenden Datensätze an. Dies geschieht, weil Access beim Hinzufügen des Unterformulars automatisch erkannt hat, dass seine Datenherkunft ein Fremdschlüsselfeld enthält, das mit dem Primärschlüsselfeld der Datenherkunft im Hauptformular verknüpft ist und die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformular-Steuerelements entsprechend gefüllt hat (s. Bild 10).<\/p>\n Bild 10: Hauptformular mit zwei synchronen Unterformular<\/span><\/b><\/p>\n Beim Unterformular-Steuerelement sfmBestelldetails <\/b>sind diese Eigenschaften hingegen leer geblieben.<\/p>\n Das ist klar – es gibt keine verwertbare Beziehung zwischen den Datenherkünften in Haupt- und Unterformular. Also probieren wir es zunächst wieder in der Variante des vorherigen Beispiels ohne Code. Wir fügen dem Hauptformular ein Textfeld namens txtBestellungID <\/b>hinzu, das den folgenden Ausdruck als Steuerelementinhalt verwendet:<\/p>\n Für die Eigenschaft Verknüpfen von <\/b>des Unterformulars sfmBestelldetails <\/b>tragen wir BestellungID <\/b>ein, für die Eigenschaft Verknüpfen nach <\/b>das Textfeld txtBestellungID<\/b>.<\/p>\n Nach dem Wechsel in die Formularansicht wird deutlich, dass alles so funktioniert wie gewünscht – beim Navigieren durch das Unterformular sfmBestellungen<\/b> ändert sich ständig der Inhalt des Unterformulars sfmBestelldetails<\/b>, und wenn der Benutzer einen neuen Kunden auswählt, passen sich gleich beide Unterformulare an.<\/p>\n Interessant ist an dieser Stelle die Betrachtung der Performance: Wenn Sie durch die Kundendatensätze im Hauptformular navigieren, werden beide Unterformulare blitzschnell angepasst.<\/p>\n Wenn Sie hingegen durch die Datensätze des Unterformulars sfmBestellungen <\/b>blättern, erhalten Sie wieder eine Verzögerung von ein paar Sekundenbruchteilen. Wenn Sie das nicht wünschen, müssen Sie auch hier wieder mit VBA arbeiten.<\/p>\n Dazu legen wir im Klassenmodul des Hauptformulars frmKundenBestellungenArtikel <\/b>prinzipiell wieder die gleichen Elemente an wie im vorherigen Beispiel – also eine mit WithEvents<\/b> deklarierte Objektvariable für das Unterformular sfmBestellungen<\/b> sowie zwei Ereignisprozeduren, von denen die erste beim Laden des Hauptformulars ausgelöst wird und die Konfiguration des zweiten Ereignisses vornimmt. Dieses wird dann beim Anzeigen eines jeden Datensatzes im Unterformular sfmBestellungen<\/b> ausgelöst und aktualisiert die Datenherkunft des zweiten Unterformulars sfmBestelldetails<\/b> (s. Listing 3).<\/p>\n Listing 3: Aktualisieren des Unterformulars sfmBestelldetails per VBA<\/span><\/b><\/p>\n übrigens wirkt es sich offensichtlich nicht sonderlich auf die Performance aus, ob Sie nun ein Textfeld im Hauptformular unterbringen, das sich den Inhalt des Primärschlüsselfeldes des ersten Unterformulars holt, und dann über die Eigenschaft Verknüpfen nach <\/b>des zweiten Unterformular-Steuerelements darauf zugreifen oder ob Sie gleich das entsprechende Feld im ersten Unterformular mit der Eigenschaft Verknüpfen nach <\/b>des zweiten Unterformulars referenzieren. Letzteres würde in diesem Fall wie folgt lauten:<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Mit diesem Beitrag haben Sie einige Möglichkeiten kennengelernt, um vom Hauptformular abhängige Unterformulare und voneinander abhängige Unterformulare zu synchronisieren. Es ist offensichtlich, dass die Lösungen, die rein auf der Verwendung von Eigenschaften wie Verknüpfen von <\/b>und Verknüpfen nach<\/b> basieren, teilweise eine schlechte Performance bieten.<\/p>\n Daher empfiehlt es sich, per VBA zu den entsprechenden Gelegenheiten nachzuhelfen – beispielsweise durch Aktualisieren des zu filternden Unterformulars.<\/p>\n Hier gibt es wieder mindestens zwei Möglichkeiten: Entweder Sie fügen die entsprechenden Ereignisprozeduren den jeweiligen Unterformularen hinzu, oder Sie steuern die Unterformulare fern, indem Sie diese vom Hauptformular aus referenzieren und deren Ereignisse dort abfangen und passende Ereignisprozeduren implementieren.<\/p>\n Dies ist die sauberere Lösung, denn so brauchen Sie den Unterformularen keinen Code hinzuzufügen, den sie – wenn sie noch anderswo als Unterformular eingesetzt werden – gar nicht gebrauchen können.<\/p>\n Enthaltene Beispieldateien:<\/p>\n 1zuNInUnterformularen.mdb<\/p>\n![\"1:n-Beziehung](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_002.png\")
<\/p>\n![\"Zwei](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_003.png\")
<\/p>\n![\"Aktuell](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_004.png\")
<\/p>\n![\"Diese](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_005.png\")
<\/p>\nForms!frmKategorienArtikelUFUF! sfmKategorienUFUF!KategorieID<\/pre>\n
Private Sub <\/span>Form_Current()\r\n Me.Parent!sfmArtikelUFUF.Form.Requery\r\nEnd Sub<\/span><\/pre>\n![\"Fehlermeldung](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_006.png\")
<\/p>\n Me.Parent.Name\r\nfrmKategorienArtikelUFUF<\/pre>\n
Me.Parent.sfmArtikelUFUF.Name\r\nsfmArtikelUFUF<\/pre>\n
Me.Parent.sfmArtikelUFUF.Form.Name<\/pre>\n
Private Sub <\/span>Form_Current()\r\n Dim <\/span>strForm As String<\/span>\r\n On Error Resume Next<\/span>\r\n strForm = Me.Parent!sfmArtikelUFUF.Form.Name\r\n On Error GoTo<\/span> 0\r\n If <\/span>Len<\/span>(strForm) > 0 Then<\/span>\r\n Me.Parent!sfmArtikelUFUF.Form.Requery\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nDim <\/span>WithEvents objSfmKategorienUFUF As <\/span>Form\r\nPrivate Sub <\/span>Form_Load()\r\n Set<\/span> objSfmKategorienUFUF = Me!sfmKategorienUFUF.Form\r\n With<\/span> objSfmKategorienUFUF\r\n .OnCurrent = \"[Event Procedure]\"\r\n End With<\/span>\r\nEnd Sub<\/span>\r\nPrivate Sub <\/span>objSfmKategorienUFUF_Current()\r\n Me!sfmArtikelUFUF.Form.Requery\r\nEnd Sub<\/span><\/pre>\n![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_007.png\")
<\/p>\n=sfmKategorienUFUF!KategorieID<\/pre>\n
![\"Verknüpfung](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_009.png\")
<\/p>\n![\"Hauptformular](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_008.png\")
<\/p>\n![\"Hauptformular](\"..\/fileadmin\/_temp_\/2014_05\/pic_952_010.png\")
<\/p>\n=sfmBestellungen!BestellungID<\/pre>\n
Dim <\/span>WithEvents objSfmBestellungen As <\/span>Form\r\nPrivate Sub <\/span>Form_Load()\r\n Set<\/span> objSfmBestellungen = Me!sfmBestellungen.Form\r\n With<\/span> objSfmBestellungen\r\n .OnCurrent = \"[Event Procedure]\"\r\n End With<\/span>\r\nEnd Sub<\/span>\r\nPrivate Sub <\/span>objSfmBestellungen_Current()\r\n Me!sfmBestelldetails.Form.Requery\r\nEnd Sub<\/span><\/pre>\nForms!frmKundenBestellungenArtikel_VBA_II!\r\nsfmBestellungen!BestellungID<\/pre>\n
Downloads zu diesem Beitrag<\/h3>\n