Manchmal legt man eine 1:n-Beziehung zwischen zwei Tabellen an, um später festzustellen, dass eine m:n-Beziehung doch die funktionalere Variante ist. Ein Beispiel sind reflexive Beziehungen, mit denen man etwa Vater-Kind-Beziehungen abbildet oder Partner-Beziehungen. Andere Beispiele sind solche wie zwischen Produkten und Kategorien – man dachte zunächst, dass es reicht, wenn man jedes Produkt nur einer Kategorie zuordnen kann, aber man dann erkennt, dass es für verschiedene Anwendungsfälle doch günstiger wäre, wenn man ein Produkt mehr als einer Kategorie zuordnen kann. Ähnliche Fälle sind Mitarbeiter und Funktionen oder Abteilungen. In diesem Beitrag schauen wir uns das Beispiel eines Kunden an, der in seinem Sportverein partnerschaftliche Beziehungen über ein Fremdschlüsselfeld der Tabelle tblMitglieder auf diese selbst abgebildet hat. Hier gab es mehrere Gründe, um diese Beziehung in eine m:n-Beziehung umzuwandeln. Welche das sind und wie wir die Umwandlung durchgeführt haben, lesen Sie in diesem Beitrag.<\/b><\/p>\n
Das Abbilden von reflexiven Beziehungen über eine 1:n-Beziehung ist an sich nicht falsch. Im Beispiel geht es um einen Sportverein, dessen Mitglieder mit einer Access-Datenbank verwaltet werden. In der Tabelle tblMitglieder gibt es zwei Felder, um die partnerschaftliche Beziehung zwischen zwei Mitgliedern abzubilden. Das erste heißt PartnerID <\/b>und dient dazu, die ID eines anderen Datensatzes dieser Tabelle zu referenzieren und damit anzugeben, welches andere Mitglied mit diesem Mitglied verbunden ist. Zusätzlich gibt es ein Ja\/Nein<\/b>-Feld namens Ehepartner<\/b>, das angibt, ob es sich um eine amtlich dokumentierte Beziehung handelt, sprich um eine eheliche Beziehung (Ja<\/b>) oder um eine Beziehung ohne Trauschein (Nein<\/b>). Der Entwurf der Tabelle sieht in abgespeckter Form wie in Bild 1 aus.<\/p>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_001.png\")
<\/p>\n
Bild 1: Entwurf der Tabelle tblMitglieder<\/span><\/b><\/p>\n Das erste Problem, das sich daraus ergibt, ist die wechselseitige Abhängigkeit. Wenn wir für Mitglied A das Mitglied B als Partner festgelegt haben, müssen wir für Mitglied B auch Mitglied A als Partner hinterlegen – und für beide muss das Feld Ehepartner<\/b> den gleichen Wert enthalten. Anderenfalls erhalten wir einen Fall von inkonsistenten Daten.<\/p>\n Diese Inkonsistenz kann nicht nur den Fall enthalten, dass die Beziehung nur in einer Richtung dokumentiert ist, etwa von Mitglied A zu Mitglied B. Es kann auch passieren, dass nicht nur Mitglied B als Partner von Mitglied A angegeben wird, sondern auch noch Mitglied C als Partner von Mitglied B. Es konnte auch vorkommen, dass ein Mitglied als Ehepartner von mehreren anderen Mitgliedern angegeben wird.<\/p>\n Das zweite Problem bei der Tabelle tblMitglieder <\/b>bei diesem Kunden war, dass bereits sehr viele andere Tabellen auf die Tabelle tblMitglieder <\/b>verwiesen hatten und somit die Grenze von maximal 32 Beziehungen erreicht war.<\/p>\n Diese Grenze gilt für Beziehungen, die über ein Fremdschlüsselfeld in dieser Tabelle hergestellt werden, wobei wir hier sehr viele Lookup-Tabellen vorgefunden haben.<\/p>\n Die Beziehung war wie in Bild 2 aufgebaut, wobei das Fremdschlüsselfeld PartnerID <\/b>auf das Feld MitgliedID <\/b>der gleichen Tabelle verweist.<\/p>\n Bild 2: Reflexive Beziehung der Mitglieder<\/span><\/b><\/p>\n Die Möglichkeit, dass ein Mitglied für mehr als ein anderes Mitglied als Partner ausgewählt wird, konnten wir durch das Setzen eines eindeutigen Schlüssels für das Fremdschlüsselfeld PartnerID <\/b>erreichen.<\/p>\n Dadurch, dass nun jede MitgliedID <\/b>nur einmal in das Feld PartnerID <\/b>eingetragen werden konnte, stellen wir sicher, dass es nur monogame Beziehungen gibt. Hier lassen wir außen vor, dass es Kulturen gibt, in denen dies möglich ist.<\/p>\n Eine weitere mögliche Fehleingabe ist die Auswahl des Mitglieds selbst als Partner.<\/p>\n Dies können wir verhindern, indem wir im Formular, das wir gleich beschreiben, nur die anderen Datensätze der Tabelle tblMitglieder <\/b>anzeigen.<\/p>\n Wenn wir sicherstellen wollen, dass die in einer Partnerschaft befindlichen Mitglieder immer wechselseitig miteinander verbunden werden, müssen wir das über die Anwendungslogik realisieren – allein über den Tabellenentwurf können wir das mit einem Fremdschlüsselfeld, das die gleiche Tabelle referenziert, nicht erreichen.<\/p>\n Wir müssen also im Formular zum Verwalten der Mitglieder eine VBA-Funktion einbauen, die beim Auswählen des Partners eines Mitglieds automatisch auch das Feld PartnerID des Partners einstellt – und die auch den gleichen Wert im Ja\/Nein<\/b>-Feld Ehepaar <\/b>für die verknüpften Datensätze festlegt.<\/p>\n Im Entwurf der Tabelle tblMitglieder <\/b>haben wir für das Fremdschlüsselfeld PartnerID <\/b>ein Nachschlagefeld definiert, damit man den Partner einfach auswählen kann (siehe Bild 3).<\/p>\n Bild 3: Auswahlfeld für den Partner<\/span><\/b><\/p>\n Um die Mitglieder zu verwalten und die Partner zuordnen zu können, haben wir ein Formular wie in Bild 4 vorgefunden.<\/p>\n Bild 4: Formular zur Mitgliederverwaltung<\/span><\/b><\/p>\n Für das Steuerelement cboPartnerID <\/b>haben wir zunächst die folgende Datensatzherkunft eingestellt, um aus allen Mitgliedern auswählen zu können:<\/p>\n Damit beim Anzeigen eines Datensatzes nicht das aktuelle Mitglied selbst erscheint und auch nicht solche Mitglieder, die bereits einer Partnerschaft zugeordnet sind, haben wir für das Ereignis Beim Anzeigen <\/b>die folgende Prozedur hinterlegt:<\/p>\n Für das Mitglied mit dem Wert 1 <\/b>im Feld MitgliedID <\/b>erhalten wir so die folgende Abfrage:<\/p>\n Damit erscheinen, wenn wir noch keinem Mitglied einen Partner zugewiesen haben, für jedes Mitglied nur die aktuell verfügbaren Partner im Feld cboPartnerID<\/b> – siehe Bild 5.<\/p>\n Bild 5: Formular zur Mitgliederverwaltung in der Formularansicht<\/span><\/b><\/p>\n Wenn wir nun für das Mitglied mit dem Wert 1 <\/b>im Feld MitgliedID <\/b>einen Partner auswählen, etwa den mit dem Wert 2<\/b>, soll für das Mitglied 2 <\/b>das Mitglied 1 <\/b>als Partner eingestellt werden.<\/p>\n Dazu hinterlegen wir für das Ereignis Nach Aktualisierung <\/b>des Kombinationsfeldes cboPartnerID <\/b>die folgende Prozedur:<\/p>\n Die so ausgeführte Aktionsabfrage lautet beispielsweise:<\/p>\n Damit erhalten wir das gewünschte Ergebnis in der zugrunde liegenden Tabelle, aber wenn wir zum Datensatz des gewählten Partners wechseln und dann zurück, zeigt das Kombinationsfeld nun für beide gar keinen Wert mehr an. Das liegt daran, dass wir die bereits vergebenen Partner vollständig ausschließen und diese somit auch für den ausgewählten Eintrag nicht mehr angezeigt werden. Das Kombinationsfeld enthält zwar den korrekten Eintrag, was wir im Direktbereich mit folgender Anweisung ermitteln können:<\/p>\n Aber da der Eintrag nicht in der Datensatzherkunft des Kombinationsfeldes enthalten ist, erscheint der Anzeigewert nicht.<\/p>\n Wir müssen die Datensatzherkunft also nochmals anpassen, indem wir mit der OR<\/b>-Klausel am Ende den gewählten Partner wieder mit in die Auswahl hineinnehmen – hier der besseren Lesbarkeit halber direkt mit den Werten 1 <\/b>für MitgliedID <\/b>und 2 <\/b>für PartnerID<\/b>:<\/p>\n Damit sehen wir nun den ausgewählten Partner sowohl für den ersten als auch für den zweiten Datensatz. In der OR<\/b>-Bedingung sorgen wir außerdem mit der Nz<\/b>-Funktion dafür, dass im Falle des Wertes NULL <\/b>im Feld PartnerID <\/b>der Wert 0 <\/b>verwendet wird – sonst erhalten wir beim Wechsel von einem Datensatz ohne PartnerID <\/b>zu einem anderen Datensatz einen Fehler.<\/p>\n Schließlich müssen wir auch noch dafür sorgen, dass der Wert für das Feld Ehepaar <\/b>für das als Partner angegebene Mitglied so einstellen wie für das Mitglied selbst. Dazu fügen wir eine Prozedur für das Ereignis Nach Aktualisierung <\/b>des Kontrollkästchens chkEhepaar <\/b>hinzu:<\/p>\n Eingangs haben wir erwähnt, dass sich viele der hier beschriebenen Probleme beheben lassen, wenn wir die reflexive Beziehung über die 1:n-Verknüpfung aufheben, die Felder PartnerID <\/b>und Ehepaar <\/b>entfernen und beides in eine m:n-Beziehung auslagern.<\/p>\n Wir schauen uns erst einmal an, wie die Verknüpfungstabelle aussieht und wie wir diese mit der Tabelle tblMitglieder <\/b>verknüpfen. Damit das Beispiel mit der reflexiven 1:n-Beziehung erhalten bleibt, erstellen wir in der Beispieldatenbank eine Kopie der Tabelle tblMitglieder <\/b>(siehe Bild 6) unter dem Namen tblMitgliederMN<\/b>. Außerdem fügen wir die Tabelle tblPartnerschaften <\/b>hinzu, die folgende Felder enthält:<\/p>\n Bild 6: Aktueller Zustand der Daten in der Tabelle tblMitglieder<\/span><\/b><\/p>\n Dadurch, dass wir einen eindeutigen Index auf die Felder PartnerA <\/b>und PartnerB <\/b>legen, stellen wir sicher, dass jedes Mitglied nur einmal als PartnerA oder PartnerB angegeben werden kann.<\/p>\n Wir haben allerdings noch eine kleine Lücke: Wir können die Kombination aus Mitglied 1 <\/b>und Mitglied 2 <\/b>immer noch zweimal angeben – einmal mit dem Wert 1 <\/b>im Feld PartnerA <\/b>und 2 <\/b>in PartnerB <\/b>und umgekehrt. Außerdem können wir theoretisch auch Mitglied 1 <\/b>sowohl in das Feld PartnerA <\/b>als auch in PartnerB <\/b>eingeben.<\/p>\n Dies verhindern wir, indem wir für die Tabelle eine Gültigkeitsregel anlegen, die wir wie in Bild 7 definieren.<\/p>\n Bild 7: Tabelle tblPartnerschaften<\/span><\/b><\/p>\n Wenn wir nun eine Partnerschaft eingeben, bei welcher der Wert von PartnerA <\/b>kleiner oder gleich der von PartnerB <\/b>ist, erhalten wir die Meldung aus Bild 8.<\/p>\n Bild 8: Meldung beim Eingeben ungültiger Daten<\/span><\/b><\/p>\n Diese Regel ist nur für den Fall vorgesehen, dass jemand versucht, Daten direkt über die Tabelle einzugeben. Das eigentliche Anlegen erledigen wir ohnehin über das Formular.<\/p>\n Damit nur Werte aus dem Primärschlüsselfeld der Tabelle tblMitglieder <\/b>eingegeben werden können, fügen wir dem Datenmodell die beiden Beziehungen aus Bild 9 hinzu.<\/p>\n Bild 9: Beziehungen für die Verwaltung von Partnerschaften per m:n-Beziehung<\/span><\/b><\/p>\n Wichtig ist hier die Richtung, in der wir die Beziehungspfeile ziehen. Da die beiden Felder PartnerA <\/b>und PartnerB <\/b>mit einem eindeutigen Index versehen wurden, müssen wir den Pfeil von tblMitglieder <\/b>auf tblPartnerschaften <\/b>ziehen, sodass die Mitgliedertabelle unter Tabelle\/Abfrage <\/b>und die Partnerschaftstabelle unter Verwandte Tabelle\/Abfrage <\/b>angegeben wird.<\/p>\n Andersherum könnten wir keine referenzielle Integrität für die Beziehungen festlegen, da dann das Feld MitgliedID <\/b>der Tabelle tblMitglieder <\/b>als Fremdschlüsselfeld betrachtet würde und es darin Werte gibt, die zurzeit noch nicht im Feld PartnerA <\/b>oder PartnerB <\/b>der Tabelle tblPartnerschaften <\/b>enthalten sind.<\/p>\n Es gibt bereits eingetragene Partnerschaften in der Tabelle tblMitarbeiterMN<\/b>, die wir nun über die Verknüpfungstabelle tblPartnerschaften <\/b>abbilden wollen.<\/p>\n Das ist anspruchsvoll, weil wir die Partnerschaften so eintragen müssen, dass der Wert im Feld PartnerA <\/b>immer kleiner als der in PartnerB <\/b>ist. Wir könnten starten, indem wir die Partnerschaften aufsteigend nach der ID des Mitglieds sortieren und zusätzlich die PartnerID<\/b> und den Ehepaar<\/b>-Status mit folgender Abfrage ausgeben lassen:<\/p>\n Dies liefert jede Partnerschaft in doppelter Ausführung, jeweils einmal mit jeder Mitglieds-ID im Feld MitgliedID <\/b>und einmal im Feld PartnerID <\/b>(siehe Bild 10).<\/p>\n Bild 10: Ausgabe aller Partnerschaften laut tblMitgliederMN<\/span><\/b><\/p>\n Wenn wir hier allerdings den Ausdruck, den wir als Gültigkeitsregel für die Tabelle tblPartnerschaften <\/b>verwendet haben, als Kriterium einsetzen, erhalten wir jede Partnerschaft nur noch einmal:<\/p>\n Für diese Abfrage aktivieren wir nun den Abfragetyp Anfügen <\/b>und geben als Zieltabelle die Tabelle tblPartnerschaften <\/b>an. Im Entwurf weisen wir das Feld MitgliedID <\/b>dem Feld PartnerA <\/b>und das Feld PartnerID <\/b>dem Feld PartnerB <\/b>hinzu. Das Feld Ehepaar <\/b>weisen wir dem gleichnamigen Feld der Tabelle tblPartnerschaften <\/b>zu (siehe Bild 11).<\/p>\n Bild 11: Anfügeabfrage für die Partnerschaftstabelle<\/span><\/b><\/p>\n Führen wir diese Abfrage aus, erhalten wir das Ergebnis aus Bild 12. Durch das Kriterium landen auch nur gültige Datensätze in dieser Abfrage – sollte die Tabelle tblMitgliederMN<\/b> zuvor Datensätze enthalten haben, bei denen PartnerA <\/b>gleich PartnerB <\/b>wäre, oder es gäbe inkonsistente Daten, würden diese nicht angelegt werden.<\/p>\n Bild 12: Ergebnis der Anfügeabfrage<\/span><\/b><\/p>\n Es ist allerdings nicht auszuschließen, dass für Mitglied 1 <\/b>eine Partnerschaft mit Mitglied 2 <\/b>angelegt war und für Mitglied 2 <\/b>eine Partnerschaft mit Mitglied 3<\/b>. Dies können wir über das Datenmodell in der aktuellen Form nicht ausschließen und müssten es letztlich über die Anwendungslogik steuern. Allerdings bietet Access auch noch die Datenmakros an. Wie wir damit auch die letzte mögliche Fehleingabe verhindern, zeigen wir in den folgenden Abschnitten.<\/p>\n Datenmakros sind eine Art Trigger für Access-Tabellen. In diesem Fall nutzen wir das Ereignis Vor Aktualisierung<\/b>, um vor dem Speichern des Datensatzes ein Datenmakro auszulösen. Dieses legen wir in der Datenblattansicht mit dem Ribbonbefehl Tabelle|Vorabereignisse|Vor Änderung <\/b>an (siehe Bild 13).<\/p>\n Bild 13: Datenmakro für das Ereignis Vor Änderung anlegen<\/span><\/b><\/p>\n In diesem Makro, dessen Entwurf wir in Bild 14 sehen, wollen wir untersuchen, ob entweder der Wert für das Feld PartnerA<\/b> oder der Wert für das Feld PartnerB <\/b>bereits in einem der vorhandenen Einträge vorkommt.<\/p>\n Bild 14: Datenmakro für das Ereignis Vor Änderung in der Entwurfsansicht<\/span><\/b><\/p>\n In den ersten vier Anweisungen legen wir zunächst einige lokale Variablen fest:<\/p>\n Danach verwenden wir die Aktion Datensatz nachschlagen <\/b>für die Tabelle tblPartnerschaften<\/b>, wo wir folgende Bedingung angeben:<\/p>\n Wir suchen also nach einem Datensatz, der nicht der aktuell bearbeitete oder neu hinzugefügte Datensatz ist ([PartnerschaftID]<>[varNeuePartnerschaftID]<\/b>), und der entweder im Feld PartnerA <\/b>oder PartnerB <\/b>bereits den neuen Wert aus der Variablen varNeuerPartnerA <\/b>enthält. Das Ergebnis referenzieren wir mit der Variablen rstPartnerschaften<\/b>.<\/p>\n Danach lesen wir den Wert des Feldes PartnerschaftID <\/b>für den neuen oder bearbeiteten Datensatz in die Variable varPartnerschaftID <\/b>ein.<\/p>\n Ist varPartnerschaftID <\/b>danach ungleich 0<\/b>, gibt es mindestens einen Datensatz, in dem der Wert des Feldes PartnerA <\/b>bereits vorkommt. Dies prüfen wir in einer Wenn<\/b>-Bedingung. Ist diese erfüllt, lösen wir den Fehler 1001 <\/b>aus und geben dafür eine Meldung aus, die wie folgt zusammengesetzt wird:<\/p>\n Hat varPartnerschaft <\/b>an dieser Stelle den Wert 0<\/b>, prüfen wir, ob der Inhalt des neuen oder bearbeiteten Datensatzes für das Feld PartnerB <\/b>bereits in einem vorhandenen Datensatz außer dem aktuellen Datensatz vorkommt. Der Ablauf ist der gleiche wie bei der Prüfung auf das Feld PartnerA<\/b>. Hier geben wir bei der Fehlermeldung allerdings den Wert des bereits vorhandenen Eintrags für das Feld PartnerB <\/b>aus.<\/p>\n Auf diese Weise fangen wir über das Datenmodell alle möglichen Fehleingaben ab. Wenn Sie das Datenmakro auf die eigene Datenbank übertragen wollen, markieren Sie einfach den kompletten Makro-Inhalt und fügen diesen in das Makro für die Zieltabelle ein. Wenn man den Inhalt der Zwischenablage in einen Texteditor einfügt, sieht man, dass es sich hierbei um ein XML-Dokument handelt. Nun schauen wir uns an, wie wir die Benutzeroberfläche auf das neue Datenmodell anpassen.<\/p>\n Bisher hatten wir im Formular frmMitglieder<\/b> einfach ein Kombinationsfeld zur Auswahl des Partners. Das können wir auch beibehalten, aber es wird ein wenig komplizierter, das Formular an das neue Datenmodell anzupassen.<\/p>\n Der erste Schritt ist, dass wir das Formular frmMitglieder <\/b>in ein neues Formular namens frmMitgliederMN <\/b>kopieren und mit diesem weiterarbeiten.<\/p>\n Dann weisen wir diesem die Kopie der Tabelle namens tblMitgliederMN <\/b>als Datensatzquelle zu (siehe Bild 15). In dieser löschen wir zuvor die beiden Felder PartnerID <\/b>und Ehepaar<\/b>, denn diese Informationen werden nun in der Tabelle tblPartnerschaften <\/b>gespeichert.<\/p>\n Bild 15: Entwurf des Formulars frmMitgliederMN<\/span><\/b><\/p>\n Außerdem entfernen wir für die beiden Steuerelemente cboPartnerID <\/b>und chkEhepaar <\/b>die Werte für die Eigenschaft Steuerelementinhalt<\/b>. Wir können diese nicht mehr direkt zuweisen, da diese nicht mehr in der Datensatzquelle des Formulars enthalten sind.<\/p>\n Die beiden Steuerelemente cboPartnerID <\/b>und chkEhepaar <\/b>sollen immer beim Anzeigen eines Datensatzes gefüllt werden. Dazu hinterlegen wir eine Ereignisprozedur für die Eigenschaft Beim Anzeigen <\/b>des Formulars, in der wir nur den Aufruf einer weiteren Prozedur hinterlegen:<\/p>\n Die Prozedur UpdateControls <\/b>finden wir in Listing 1. Sie hat die Aufgabe, die beiden nicht gebundenen Steuerelemente mit den jeweiligen Werten aus der Tabelle tblPartnerschaften <\/b>zu füllen.<\/p>\n Listing 1: Prozedur zum Aktualisieren der Steuerelemente cboPartnerID und chkEhepaar<\/span><\/b><\/p>\n Sie deklariert zunächst einige Variablen, unter anderem für das aktuelle Database<\/b>-Objekt und für ein Recordset auf Basis der Tabelle tblPartnerschaften<\/b>. Außerdem benötigen wir eine Variable zum Zusammenstellen einer SQL-Abfrage (strSQL<\/b>), zum Referenzieren des jeweiligen Partners des aktuellen Mitglieds (varPartnerID<\/b>) und für die Angabe, ob es sich bei der Partnerschaft um ein Ehepaar handelt (bolEhepaar<\/b>).<\/p>\n Im ersten Schritt prüft die Prozedur, ob das Formular aktuell einen nicht neuen (Not Me.NewRecord<\/b>) oder einen in Bearbeitung befindlichen Datensatz anzeigt (Me.Dirty<\/b>). Ist eine der beiden Bedingungen wahr, werden die beiden Steuerelemente cboPartnerID <\/b>und chkEhepaar <\/b>aktiviert. Anderenfalls werden sie deaktiviert.<\/p>\n Dies sorgt dafür, dass die beiden Steuerelemente bei einem neuen, leeren Datensatz, der noch nicht bearbeitet wurde, noch nicht zur Auswahl eines Partners genutzt werden können. Das ist notwendig, da es zu diesem Zeitpunkt noch keinen Wert im Feld MitgliedID <\/b>gibt, den wir in die Tabelle tblPartnerschaften <\/b>eintragen könnten.<\/p>\n Danach füllen wir ein Recordset mit den Datensätzen der Tabelle tblPartnerschaften<\/b>. Die folgenden Schritte dienen dazu, herauszufinden, ob das aktuell angezeigte Mitglied bereits einen Partner hat. Dazu durchsuchen wir das Recordset zunächst mit rst.FindFirst <\/b>nach einem Datensatz, der die MitgliedID <\/b>des aktuell angezeigten Mitglieds im Feld PartnerB <\/b>enthält.<\/p>\n Ist das der Fall, liefert die Eigenschaft NoMatch <\/b>den Wert False <\/b>und die erste Bedingung ist erfüllt. Wenn in PartnerB <\/b>das aktuelle Mitglied ist, können wir aus dem Feld PartnerA <\/b>den Partner des aktuellen Mitglieds entnehmen und diesen in die Variable varPartnerID <\/b>eintragen. Außerdem lesen wir aus dem Feld Ehepaar <\/b>den Wert für die Variable bolEhepaar <\/b>aus.<\/p>\n Sollten wir keinen Datensatz finden, in dem für das Feld PartnerB <\/b>die ID des aktuell angezeigten Mitglieds eingetragen ist, durchsuchen wir in nächsten Schritt das Feld PartnerA <\/b>nach diesem Wert.<\/p>\n Finden wir einen passenden Eintrag, legen wir varPartnerID <\/b>auf den Wert des Feldes PartnerB <\/b>fest und bolEhepaar <\/b>wieder auf den Wert aus dem Feld Ehepaar<\/b>.<\/p>\n Liefert auch diese Suche kein Ergebnis, stellen wir varPartner <\/b>auf Null <\/b>und bolEhepaar <\/b>auf False <\/b>ein. Letzteres ist nicht unbedingt nötig, da ein Boolean<\/b>-Feld ohnehin mit dem Wert False <\/b>initialisiert wird, aber die Variant<\/b>-Variable varPartnerID <\/b>hat standardmäßig den Wert Empty <\/b>und muss mit Null <\/b>gefüllt werden, damit die folgenden Schritte funktionieren.<\/p>\n Schließlich stellen wir das Steuerelement cboPartnerID <\/b>auf den Wert aus varPartnerID <\/b>ein und das Steuerelement chkEhepaar <\/b>auf den Wert aus bolEhepaar<\/b>.<\/p>\n Danach prüfen wir, ob cboPartner <\/b>nun einen Wert enthält, und aktivieren in diesem Fall das Kontrollkästchen chkEhepaar<\/b>.<\/p>\n Schließlich stellen wir die Datensatzherkunft für das Kombinationsfeld cboPartnerID <\/b>zusammen, das alle verfügbaren Mitglieder anzeigen soll.<\/p>\n Die benötigte SQL-Anweisung soll alle Datensätze der Tabelle tblMitglieder <\/b>liefern, die folgende Bedingungen erfüllen:<\/p>\n Wenn wir die Abfrage beispielsweise für das Mitglied mit der ID 1 <\/b>und mit der Partnerin mit der ID 2 <\/b>zusammenstellen, sieht diese wie in Bild 16 aus.<\/p>\n Bild 16: Abfrage zum Ermitteln der möglichen Partner<\/span><\/b><\/p>\n Der erste Teil der WHERE<\/b>-Klausel schließt das aktuelle Mitglied aus der Ergebnisliste aus. Der zweite Teil holt alle Mitglieder, deren MitgliedID <\/b>weder im Feld PartnerA <\/b>noch im Feld PartnerB <\/b>der Tabelle tblPartnerschaften <\/b>enthalten ist. Der letzte Teil stellt sicher, dass auch der aktuelle Partner des Mitglieds in der Auswahl erscheint.<\/p>\n Da das Steuerelement cboPartnerID <\/b>ungebunden ist, müssen wir einen neu ausgewählten Eintrag per VBA-Code in der Tabelle tblPartnerschaften <\/b>speichern.<\/p>\n Dazu wird das Ereignis Nach Aktualisierung <\/b>dieses Steuerelements verwendet, für das wir die folgende Prozedur hinterlegen:<\/p>\n Die Prozedur prüft, ob das Kombinationsfeld cboPartnerID <\/b>nach der Aktualisierung einen Wert enthält. In diesem Fall wird das Steuerelement chkEhepaar <\/b>aktiviert. Wenn das Kombinationsfeld cboPartnerID <\/b>geleert wurde, wird chkEhepaar <\/b>deaktiviert.<\/p>\n Außerdem wird die Prozedur SavePartner <\/b>aufgerufen, welche das eigentliche Speichern des ausgewählten Partners übernimmt. Diese Prozedur finden Sie in Listing 2.<\/p>\n Listing 2: Prozedur zum Speichern des neu gewählten Partners<\/span><\/b><\/p>\n Die Prozedur deklariert ein Database<\/b>-Objekt sowie zwei Variablen für den ersten und den zweiten Partner der Partnerschaft (lngPartnerA <\/b>und lngPartnerB<\/b>). Außerdem benötigen wir eine String<\/b>-Variable für das Feld Ehepaar<\/b>.<\/p>\n Die Prozedur speichert zunächst mit Me.Dirty = False <\/b>den aktuellen Datensatz im Formular.<\/p>\n Dann prüft sie, ob der Wert des Kombinationsfeldes cboPartnerID <\/b>nicht Null <\/b>ist. Ist das nicht der Fall, untersucht sie, ob der Wert des Feldes MitgliedID <\/b>des aktuellen Mitglieds aus dem Formular größer ist als die ID des gewählten Partners aus dem Kombinationsfeld cboPartnerID<\/b>.<\/p>\n Diese Unterscheidung ist nötig, damit wir festlegen können, welcher Partner als PartnerA <\/b>und welcher als PartnerB <\/b>eingetragen wird. Zur Erinnerung: Wir hatten als Gültigkeitsregel in der Tabellendefinition festgelegt, dass die ID von PartnerA <\/b>immer kleiner als die von PartnerB <\/b>sein muss.<\/p>\n Ist MitgliedID <\/b>größer als die PartnerID <\/b>ist, wird die MitgliedID <\/b>in der Variablen lngPartnerB <\/b>und die ID des Partners in lngPartnerA <\/b>gespeichert und umgekehrt.<\/p>\n Wenn das Kontrollkästchen chkEhepaar <\/b>aktiviert ist, erhält die Variable strEhepaar <\/b>die Zeichenkette True<\/b>, sonst False<\/b>. Warum speichern wir diesen Wert als String?<\/p>\n Weil wir diesen gleich in einer INSERT INTO<\/b>-Anweisung nutzen wollen und wir dort nicht direkt einen Boolean<\/b>-Wert angeben können, da dieser in der deutschen Access-Version als Wahr <\/b>oder Falsch <\/b>interpretiert wird, was einen Fehler auslösen würde.<\/p>\n Danach entfernen wir zunächst die Einträge aus der Tabelle tblPartnerschaften<\/b>, die im Feld PartnerA <\/b>oder PartnerB <\/b>einen der beiden Werte aus lngPartnerA <\/b>oder lngPartnerB <\/b>enthalten.<\/p>\n Dies ist nötig, wenn wir den Partner eines Mitglieds austauschen, statt diesen für einen bisher nicht vorhandenen Partner hinzuzufügen.<\/p>\n Danach können wir schließlich die neue Partnerschaft in die Tabelle tblPartnerschaften <\/b>eintragen, was wir mit einer INSERT INTO<\/b>-Anweisung erledigen.<\/p>\n Wenn wir beispielsweise für das Mitglied 1 <\/b>das Mitglied 2 <\/b>eintragen, und die Partnerschaft als Ehepaar definiert werden soll, sieht die Abfrage wie folgt aus:<\/p>\n Schließlich fehlt noch der Else<\/b>-Teil der Bedingung, die geprüft hat, ob überhaupt ein neuer Partner ausgewählt oder gegebenenfalls der vorhandene Partner entfernt wurde.<\/p>\n Wurde der Partner entfernt, rufen wir eine DELETE<\/b>-Anweisung auf, welche die Partnerschaft entfernt, an der das aktuell angezeigte Mitglied als PartnerA <\/b>oder PartnerB <\/b>beteiligt ist. Wenn wir die Partnerschaft für das Mitglied mit der ID 1 <\/b>entfernen, sieht die Abfrage wie folgt aus:<\/p>\n Wenn wir für eine bestehende Partnerschaft im Formular die Eigenschaft Ehepaar <\/b>setzen oder entfernen, löst dies das Ereignis ![\"Reflexive](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_002.png\")
<\/p>\nMehrere Partner für das gleiche Mitglied verhindern<\/h2>\n
Auswahl einer Beziehung mit sich selbst verhindern<\/h2>\n
Nur eindeutige Partnerschaften erlauben<\/h2>\n
![\"Auswahlfeld](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_003.png\")
<\/p>\nFormular zum Verwalten der Mitglieder und Partnerschaften<\/h2>\n
![\"Formular](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_004.png\")
<\/p>\nSELECT MitgliedID, Vorname & '' '' & Nachname FROM tblMitglieder<\/pre>\n
Private Sub <\/span>Form_Current()\r\n Me.cboPartnerID.RowSource = \"SELECT MitgliedID, \" _\r\n & \"Vorname & '' '' & Nachname FROM tblMitglieder \" _\r\n & \"WHERE NOT (MitgliedID = \" & Me.MitgliedID & \") \" _\r\n & \" AND (MitgliedID NOT IN (\" _\r\n & \" SELECT PartnerID FROM tblMitglieder \" _\r\n & \" WHERE PartnerID IS NOT NULL))\"\r\nEnd Sub<\/span><\/pre>\nSELECT MitgliedID, Vorname & '' '' & Nachname \r\nFROM tblMitglieder \r\nWHERE NOT (MitgliedID = 1) \r\nAND (MitgliedID NOT IN (\r\n SELECT PartnerID FROM tblMitglieder \r\n WHERE PartnerID IS NOT NULL)\r\n)<\/pre>\n
![\"Formular](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_005.png\")
<\/p>\nPartnerschaft für den Partner einstellen<\/h2>\n
Private Sub <\/span>cboPartnerID_AfterUpdate()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Set<\/span> db = CurrentDb\r\n db.Execute \"UPDATE tblMitglieder SET PartnerID = \" _\r\n & Me.MitgliedID & \" WHERE MitgliedID = \" _\r\n & Me.cboPartnerID, dbFailOnError\r\nEnd Sub<\/span><\/pre>\nUPDATE tblMitglieder SET PartnerID = 1 WHERE MitgliedID = 2<\/pre>\n
Screen.ActiveControl.Value\r\n 2 <\/pre>\n
SELECT MitgliedID, Vorname & '' '' & Nachname \r\nFROM tblMitglieder \r\nWHERE NOT (MitgliedID = 1) AND (MitgliedID NOT IN (\r\n SELECT PartnerID FROM tblMitglieder \r\n WHERE PartnerID IS NOT NULL) \r\nOR MitgliedID = 2)<\/pre>\n
Private Sub <\/span>chkEhepaar_AfterUpdate()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Set<\/span> db = CurrentDb\r\n db.Execute \"UPDATE tblMitglieder SET Ehepaar = \" _\r\n & IIf(Me.chkEhepaar = True, \"True\", \"False\") _\r\n & \" WHERE MitgliedID = \" & Me.cboPartnerID, _\r\n dbFailOnError\r\nEnd Sub<\/span><\/pre>\nWarum auf m:n-Beziehung umstellen?<\/h2>\n
![\"Aktueller](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_006.png\")
<\/p>\n\n
![\"Tabelle](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_007.png\")
<\/p>\n![\"Meldung](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_008.png\")
<\/p>\nBeziehung zwischen Mitgliedern und Partnerschaften<\/h2>\n
![\"Beziehungen](\"..\/fileadmin\/_temp_\/2026_01\/02-01-2026_16-04-39.png\")
<\/p>\nDaten migrieren<\/h2>\n
SELECT\r\n tblMitgliederMN.MitgliedID,\r\n tblMitgliederMN.PartnerID,\r\n tblMitgliederMN.Ehepaar\r\nFROM\r\n tblMitgliederMN\r\nWHERE\r\n (((tblMitgliederMN.PartnerID) IS NOT NULL))\r\nORDER BY\r\n tblMitgliederMN.MitgliedID;<\/pre>\n
![\"Ausgabe](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_009.png\")
<\/p>\nSELECT\r\n tblMitgliederMN.MitgliedID,\r\n tblMitgliederMN.PartnerID,\r\n tblMitgliederMN.Ehepaar\r\nFROM\r\n tblMitgliederMN\r\nWHERE\r\n (\r\n ((tblMitgliederMN.MitgliedID) < [PartnerID])\r\n AND ((tblMitgliederMN.PartnerID) IS NOT NULL)\r\n )\r\nORDER BY\r\n tblMitgliederMN.MitgliedID;<\/pre>\n
![\"Anfügeabfrage](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_010.png\")
<\/p>\n![\"Ergebnis](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_011.png\")
<\/p>\nDoppelte Eingabe in verschiedenen Feldern per Datenmakro verhindern<\/h2>\n
![\"Datenmakro](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_012.png\")
<\/p>\n![\"Datenmakro](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_013.png\")
<\/p>\n\n
[PartnerschaftID]<>[varNeuePartnerschaftID] Und ([PartnerA]=[varNeuerPartnerA] Oder [PartnerB]=[varNeuerPartnerA])<\/pre>\n
=\"Mitglied \" & [varNeuerPartnerA] & \" vorhanden\"<\/pre>\n
Formular an das neue Datenmodell anpassen<\/h2>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_014.png\")
<\/p>\nFüllen der Steuerelemente cboPartnerID und chkEhepaar<\/h2>\n
Private Sub <\/span>Form_Current()\r\n Call<\/span> UpdateControls\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>UpdateControls()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>strSQL As String<\/span>\r\n Dim <\/span>varPartnerID As Variant<\/span>\r\n Dim <\/span>bolEhepaar As Boolean<\/span>\r\n \r\n If <\/span>Not<\/span> Me.NewRecord Or Me.Dirty Then<\/span>\r\n Me.cboPartnerID.Enabled = True<\/span>\r\n Me.chkEhepaar.Enabled = True<\/span>\r\n Else<\/span>\r\n Me.cboPartnerID.Enabled = False<\/span>\r\n Me.chkEhepaar.Enabled = False<\/span>\r\n End If<\/span>\r\n \r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM tblPartnerschaften\", dbOpenDynaset)\r\n rst.FindFirst \"PartnerB = \" & Nz(Me.MitgliedID, 0)\r\n If <\/span>Not<\/span> rst.NoMatch Then<\/span>\r\n varPartnerID = rst!PartnerA\r\n bolEhepaar = rst!Ehepaar\r\n Else<\/span>\r\n rst.FindFirst \"PartnerA = \" & Nz(Me.MitgliedID, 0)\r\n If <\/span>Not<\/span> rst.NoMatch Then<\/span>\r\n varPartnerID = rst!PartnerB\r\n bolEhepaar = rst!Ehepaar\r\n Else<\/span>\r\n varPartnerID = Null\r\n bolEhepaar = False<\/span>\r\n End If<\/span>\r\n End If<\/span>\r\n Me.cboPartnerID = varPartnerID\r\n Me.chkEhepaar = bolEhepaar\r\n If <\/span>Not<\/span> (Nz(Me.cboPartnerID, 0) = 0) Then<\/span>\r\n Me.chkEhepaar.Enabled = True<\/span>\r\n Else<\/span>\r\n Me.chkEhepaar.Enabled = False<\/span>\r\n End If<\/span>\r\n strSQL = \"SELECT MitgliedID, Vorname & '' '' & Nachname AS Mitglied FROM tblMitgliederMN WHERE (((MitgliedID) <> \" _\r\n & Nz(Me.MitgliedID, 0) & \" AND (MitgliedID) NOT IN (SELECT PartnerA FROM tblPartnerschaften) \" _\r\n & \"AND (MitgliedID) NOT IN (SELECT PartnerB FROM tblPartnerschaften))) OR MitgliedID = \" _\r\n & Nz(varPartnerID, 0) & \";\"\r\n Me.cboPartnerID.RowSource = strSQL\r\nEnd Sub<\/span><\/pre>\nKombinationsfeld cboPartnerID füllen<\/h2>\n
\n
![\"Abfrage](\"..\/fileadmin\/_temp_\/2026_01\/pic_1587_015.png\")
<\/p>\nSpeichern eines neu ausgewählten Partners<\/h2>\n
Private Sub <\/span>cboPartnerID_AfterUpdate()\r\n If <\/span>Not<\/span> (Nz(Me.cboPartnerID, 0) = 0) Then<\/span>\r\n Me.chkEhepaar.Enabled = True<\/span>\r\n Else<\/span>\r\n Me.chkEhepaar.Enabled = False<\/span>\r\n End If<\/span>\r\n Call<\/span> SavePartner\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>SavePartner()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>lngPartnerA As Long<\/span>\r\n Dim <\/span>lngPartnerB As Long<\/span>\r\n Dim <\/span>strEhepaar As String<\/span>\r\n \r\n Set<\/span> db = CurrentDb\r\n Me.Dirty = False<\/span>\r\n \r\n If <\/span>Not<\/span> Len<\/span>(Nz(Me.cboPartnerID, \"\")) = 0 Then<\/span>\r\n If <\/span>Me.MitgliedID > CLng(Me.cboPartnerID) Then<\/span>\r\n lngPartnerA = Me.cboPartnerID\r\n lngPartnerB = Me.MitgliedID\r\n Else<\/span>\r\n lngPartnerA = Me.MitgliedID\r\n lngPartnerB = Me.cboPartnerID\r\n End If<\/span>\r\n If <\/span>Me.chkEhepaar = True<\/span> Then<\/span>\r\n strEhepaar = \"True\"\r\n Else<\/span>\r\n strEhepaar = \"False\"\r\n End If<\/span>\r\n db.Execute \"DELETE FROM tblPartnerschaften WHERE PartnerA IN (\" & lngPartnerA & \", \" _\r\n & lngPartnerB & \") OR PartnerB IN (\" & lngPartnerA & \", \" & lngPartnerB & \")\", dbFailOnError\r\n db.Execute \"INSERT INTO tblPartnerschaften(PartnerA, PartnerB, Ehepaar) VALUES(\" _\r\n & lngPartnerA & \", \" & lngPartnerB & \", \" & strEhepaar & \")\", dbFailOnError\r\n Else<\/span>\r\n db.Execute \"DELETE FROM tblPartnerschaften WHERE \" & Me.MitgliedID & \" IN (PartnerA, PartnerB)\", dbFailOnError\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nINSERT INTO tblPartnerschaften(PartnerA, PartnerB, Ehepaar) VALUES(1, 2, False<\/span>)<\/pre>\nDELETE FROM tblPartnerschaften \r\nWHERE 1 IN (PartnerA, PartnerB)<\/pre>\n
Ehepaar-Eigenschaft setzen oder entfernen<\/h2>\n