<\/p>\n
Im Beitrag „Verknüpfte Daten suchen“ haben wir eine Lösung beschrieben, die man zwar prima in eine Datenbank integrieren und dann dort nutzen kann. Allerdings ist es doch aufwändig, jedes Mal erst die benötigten Objekte zu importieren – und außerdem steigert das Verteilen des gleichen Codes auf viele verschiedene Datenbanken nicht unbedingt die Wartbarkeit. Da die genannte Lösung nicht für den Benutzer, sondern eher für den Entwickler gedacht ist, wollen wir diese in ein Add-In umwandeln. Dieser Beitrag zeigt die Vorgehensweise und auch die Fallstricke.<\/b><\/p>\n
Die umzuwandelnde Datenbank enthält zwei Formulare, von denen eines ein Unterformular ist, sowie eine Tabelle. Beim Aufrufen des Add-Ins über den entsprechenden Ribbon-Eintrag soll das Hauptformular der Anwendung geöffnet werden. Wir gehen nun Schritt für Schritt vor, um die Fallstricke Stück für Stück zu entschärfen.<\/p>\n
Aufmerksame Leser unseres Magazins wissen, dass eine Tabelle namens USysRegInfo <\/b>für ein Add-In unerlässlich ist. Diese speichert die Informationen, die beim Hinzufügen des Add-Ins zur Liste der Add-Ins der Anwendung in die Registry geschrieben werden, damit Access dieses Add-In in der Add-In-Liste anzeigt.<\/p>\n
Dort steht dann beispielsweise, wo die Add-In-Datenbank gespeichert ist und welche Funktion aufgerufen werden soll, wenn der Benutzer das Add-In startet. In unserem Fall sieht die Tabelle wie in Bild 1 aus. Die erste Zeile gibt an, dass beim Starten des Add-Ins eine Funktion namens Autostart <\/b>aufgerufen werden soll.<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2017_02\/pic_1083_001.png\")
<\/p>\n
Bild 1: Die Tabelle USysRegInfo<\/span><\/b><\/p>\n Die zweite enthält das Verzeichnis, in dem das Add-In gespeichert sein wird. |ACCDIR <\/b>wird beim Registrieren automatisch durch das Add-In-Verzeichnis ersetzt.<\/p>\n Neben der Tabelle müssen wir also eine Funktion definieren, welche beim Start des Add-Ins aufgerufen wird, und dort die durchzuführenden Schritte eintragen. In unserem Fall wollen wir nur das Formular frmTabellen <\/b>aufrufen.<\/p>\n Die Funktion legen wir in einem neuen Standardmodul namens mdlAddIn <\/b>an:<\/p>\n Damit das Add-In im Add-In-Manager eine gute Figur abgibt, stellen Sie ein paar Eigenschaften für die Anwendung ein. Dazu gehören der Titel<\/b>, die Firma <\/b>und der Kommentar <\/b>(s. Bild 2).<\/p>\n Bild 2: ändern der Eigenschaften der Access-Anwendung<\/span><\/b><\/p>\n Damit die Add-In-Datenbank als solche erkannt wird, ändern Sie die Dateiendung der Datenbank von .accdb <\/b>auf .accda<\/b>.<\/p>\n Nun können Sie das Add-In bereits registrieren. Dazu schließen Sie die Anwendung und öffnen eine beliebige andere Datenbankanwendung in Access. Wählen Sie dann den Ribbon-Eintrag Datenbanktools|Add-Ins|Add-Ins|Add-In-Manager <\/b>aus. Klicken Sie auf die Schaltfläche Neues hinzufügen…<\/b>, um einen Datei öffnen<\/b>-Dialog zu öffnen und die .accda<\/b>-Datenbank auszuwählen. Nach der Auswahl unserer Datei wird diese wie in Bild 3 im Add-In-Manager angezeigt. Hier finden Sie dann auch die änderungen in den Eigenschaften der Anwendung wieder.<\/p>\n Bild 3: Add-In-Manager von Access<\/span><\/b><\/p>\n Der erste Startversuch durch Anklicken des neuen Eintrags in der Add-In-Liste im Ribbon führt dann gleich zum ersten Fehler (s. Bild 4). Gewohnheitsmäßig werden Sie nun auf die Schaltfläche Debuggen <\/b>klicken und sich den Fehler ansehen – hierzu folgt später eine Warnung!<\/p>\n Bild 4: Fehler beim Versuch, das neue Add-In zu starten<\/span><\/b><\/p>\n Schauen wir zunächst auf den Fehler: Access kann die Tabelle tblArtikel<\/b>, die als Datenherkunft des Formulars angegeben werden soll, nicht finden. Das hat normalerweise den Grund, dass keine solche Tabelle in der Datenbank enthalten ist.<\/p>\n In diesem Fall haben wir das Add-In aber zum Experimentieren von einer Datenbank aus geöffnet, die wir mit genau den gleichen Tabellen ausgestattet haben, die wir auch schon beim Erstellen des Add-Ins zum Testen verwendet haben. Grundsätzlich ist die Tabelle also vorhanden.<\/p>\n Allerdings greift das Add-In standardmäßig auf die Tabellen in der Add-In-Datenbank zu – aber dort befindet sich ja nur noch die Tabelle tblKonfigurationen<\/b>! Die Tabelle tblArtikel <\/b>jedoch befindet sich in der Host-Datenbank und kann somit nicht so einfach als Datenherkunft eines Formulars in der Add-In-Datenbank verwendet werden. Wie wir dies lösen, schauen wir uns gleich an. Bevor wir uns ans Werk machen, jedoch noch die versprochene Warnung.<\/p>\n Wie erwähnt, möchte man beim Auftauchen von Fehlern in Add-Ins genau wie bei normalen Datenbanken gleich in den VBA-Editor eintauchen und den Fehler beheben. Wenn Sie allerdings Elemente einer Add-In-Datenbank ändern, während diese von einer anderen Access-Datenbank als Add-In geöffnet wurde, werden diese änderungen nicht gespeichert! Sie können zwar temporär änderungen durchführen und auch testen, aber Sie sollten, wenn Sie dies vorhaben, beispielsweise änderungen am Code in die Zwischenablage kopieren, die Datenbank schließen, die Add-In-Datenbank öffnen und dort die änderungen reproduzieren.<\/p>\n Erst danach können Sie die änderungen durch erneuten Aufruf des Add-Ins in der Host-Datenbank testen. Das ist leider etwas umständlich, aber nicht zu ändern.<\/p>\n Hierbei gibt es aber noch einen Fallstrick: Durch das Hinzufügen der Datenbank zur Add-In-Liste wurde diese in den Add-In-Ordner kopiert. Sie müssen also auch noch aufpassen, dass Sie die änderungen an der richtigen Datenbank durchführen. Es gibt zwei Möglichkeiten:<\/p>\n Wenn Sie änderungen an Stellen vornehmen, welche die Funktion als Add-In an sich betreffen – also beispielsweise Einstellungen der Anwendungseigenschaften oder in der Tabelle USysRegInfo <\/b>-, müssen Sie das Add-In auch neu registrieren.<\/p>\n Die Zeile, die den obigen Fehler ausgelöst hat, befindet sich in der folgenden Prozedur:<\/p>\n Gibt es eine Alternative zum Zuweisen des Namens der Tabelle zur Eigenschaft RecordSource <\/b>des Unterformulars Wir könnten versuchen, ein Recordset auf Basis dieser Tabelle zu erstellen und dieses der Eigenschaft Recordset <\/b>des Unterformulars zuweisen. Dazu benötigen wir zunächst eine Database<\/b>-Variable und jeweils eine Recordset<\/b>-Variable für die vier Unterformulare. Die Database<\/b>-Variable füllen wir wie üblich mit der Funktion CurrentDb<\/b>.<\/p>\n Den Recordset-Variablen weisen wir dann mit der OpenRecordset<\/b>-Methode das Recordset auf Basis der im entsprechenden Kombinationfeld festgelegten Tabelle zu. Schließlich bekommt die Recordset<\/b>-Eigenschaft der vier Unterformulare jeweils das entsprechende Recordset zugewiesen – hier die gekürzte Fassung der geänderten Prozedur:<\/p>\n <\/p>\n Mit dieser änderung öffnet sich das Formular zumindest schon einmal fehlerfrei.<\/p>\n Aber warum gelingt dies nun so reibungslos Greifen wir mit den Recordsets auf Basis des mit CurrentDb <\/b>gelieferten Database<\/b>-Objekts nicht auch auf die Tabellen der Add-In-Datenbank zu Genau das geschieht nicht: CurrentDb <\/b>bezieht sich immer auf die Host-Datenbank. Wenn Sie per VBA\/DAO auf eine Tabelle der Add-In-Datenbank zugreifen wollen, müssen Sie statt CurrentDb <\/b>die Funktion CodeDb <\/b>nutzen. Diese liefert einen Verweis auf das Database<\/b>-Objekt der Add-In-Datenbank.<\/p>\n Allerdings ist noch nicht alles Gold, was glänzt: Das Kombinationsfeld cboTabelle1 <\/b>zeigt, wie die übrigen Kombinationsfelder zur Auswahl der Tabellen, nur die Tabellen der Add-In-Datenbank an (s. Bild 5). Also müssen wir wohl auch hier nochmal Hand anlegen und die RowSource<\/b>-Eigenschaft durch entsprechende Recordsets ersetzen.<\/p>\n Bild 5: Das Add-In zeigt seine eigenen Tabellen im Kombinationsfeld an.<\/span><\/b><\/p>\n Bisher hatten wir dort den folgenden Ausdruck als Wert der Eigenschaft Datensatzherkunft <\/b>verwendet:<\/p>\n Diesen müssen wir nun beim öffnen des Formulars einem Recordset zuweisen und dieses dann für die Eigenschaft Recordset<\/b> der Kombinationsfelder hinterlegen. Dies erledigen wir in der Ereignisprozedur Form_Load<\/b> des Formulars (s. Listing 1). Hier erstellen wir ein Recordset auf Basis des soeben genannten SQL-Ausdrucks auf Basis der Tabelle MSysObjects <\/b>und weisen diesen der Variablen rst <\/b>zu. Dann weisen wir dieses Recordset den vier Kombinationsfeldern cboTabellen1 <\/b>bis cboTabellen4 <\/b>zu.<\/p>\n Listing 1: Füllen der Kombinationsfelder zur Auswahl der Tabellen<\/span><\/b><\/p>\n Auch dies bringt die gewünschte Lösung.<\/p>\n Als Nächstes meckert Access, wenn Sie eine der Tabellen in einem der Kombinationsfelder cboTabellen1 <\/b>bis cboTabellen4 <\/b>auswählen. Dann scheitert in der Prozedur, die durch das Nach Aktualisierung<\/b>-Ereignis ausgelöst wird, die Zuweisung der ausgewählten Tabelle an die Unterformulare. Deshalb müssen Sie auch die vier Prozeduren cboTabellen1_AfterUpdate<\/b> bis cboTabellen4_AfterUpdate <\/b>erweitern. Wie das für die erste Ereignisprozedur aussieht, haben wir in Listing 2 abgebildet. Die ersten vier Zeilen sind neu, hier werden Database<\/b>– und Recordset<\/b>-Objekt deklariert und gefüllt. Unten wird die auskommentierte Zeile durch die darüber liegende Zeile ersetzt, die der Recordset<\/b>-Eigenschaft des Unterformulars das Recordset aus rst <\/b>zuweist.<\/p>\n Listing 2: Anpassung der Prozedur, die nach dem Auswählen der anzuzeigenden Tabelle ausgelöst wird<\/span><\/b><\/p>\n Interessant ist, dass die Kombinationsfelder cboPrimaerschluessel1 <\/b>bis cboPrimaerschluessel3 <\/b>und cboFremdschluessel2 <\/b>bis cboFremdschluessel4 <\/b>von Anfang an reibungslos funktionieren. Diese haben ja den Herkunfts-typ Feldliste<\/b>, was bedeutet, dass sie die Felder der als Datensatzherkunft zugewiesenen Tabelle anzeigen. Da sich dies nicht mit einem Recordset abbilden lässt, hatten wir schon damit gerechnet, dass wir hier eine Wertliste auf Basis der jeweiligen Tabelle zusammenstellen und den Kombinationsfeldern zuweisen müssten. Allerdings scheint die Wertliste intern auch über das mit CurrentDb<\/b> gelieferte Database<\/b>-Objekt gefüttert zu werden, sodass diese nach wie vor die gewünschten Ergebnisse anzeigt.<\/p>\n Damit arbeitet das Add-In für unsere Beispielkonfiguration fehlerfrei. Wenn Sie es allerdings im aktuellen Zustand in einer anderen Datenbank öffnen, knallt es: Das Formular lädt ja immer den ersten Eintrag der Tabelle tblKonfigurationen <\/b>als Konfiguration. Dort sind die zu ladenden Tabellen samt Primär- und Fremdschlüsselfeldern gespeichert. Wenn Sie nun versuchen, in einer Datenbank mit einem völlig anderen Datenmodell auf die Tabellen der Suedsturm-Anwendung zuzugreifen, lösen Sie natürlich wieder neue Fehler aus.<\/p>\n Also müssen wir uns überlegen, wie wir die Anwendung dazu bringen, nur die für die aktuelle Host-Datenbank gültigen Konfigurationen anzuzeigen. Der Ansatz ist, die in den Konfigurationen enthaltenen Tabellen mit den in der Host-Datenbank enthaltenen Tabellen abzugleichen und nur diejenigen Einträge der Tabelle tblKonfigurationen <\/b>in den Kombinationsfeldern anzuzeigen, deren Tabellen alle in der Host-Datenbank vorkommen. Um dies zu realisieren, ist jedoch ein wenig VBA-Code nötig.<\/p>\n Um zu prüfen, ob alle in einer Konfiguration enthaltenen Tabellen auch in der Host-Datenbank vorhanden sind, müssen wir die Daten der Felder Tabelle1 <\/b>bis Tabelle4 <\/b>der Tabelle tblKonfigurationen <\/b>mit den in der Systemtabelle MSysObjects <\/b>gespeicherten Namen der Tabellen abgleichen.<\/p>\n Der erste Ansatz dazu ist die Abfrage aus Bild 6. Hier haben wir auf der einen Seite die Tabelle tblKonfigurationen<\/b>, welche ja in den Feldern Tabelle1 <\/b>bis Tabelle4 <\/b>eine bis vier an der Konfiguration beteiligte Tabellen enthält. Auf der anderen Seite haben wir vier Kopien der Tabelle MSysObjects <\/b>in den Entwurf der Abfrage gezogen. Dabei haben wir jeweils eines der Tabelle…<\/b>-Felder mit dem Feld Name <\/b>der Tabelle MSysObjects <\/b>verknüpft und in den Verknüpfungseigenschaften eingestellt, dass alle Datensätze der Tabelle tblKonfigurationen <\/b>angezeigt werden sollen, auch wenn dazu kein verknüpfter Datensatz in der Tabelle MSysObjects <\/b>enthalten ist. Daraus zeigen wir nun in den ersten vier Paaren von Ausgabefeldern der Abfrage jeweils den Namen der Tabelle1 <\/b>bis Tabelle4 <\/b>an sowie den entsprechenden, im Feld Name <\/b>der zugeordneten Kopie der Tabelle MSysObjects <\/b>enthaltenen Wert.<\/p>\n Bild 6: Abfrage, um zu prüfen, ob alle in einer Konfiguration enthaltenen Tabellen auch in der Datenbank enthalten sind<\/span><\/b><\/p>\n Diese Ausgaben sind nur zur Kontrolle und sehen wie die Spalten zwei bis neun aus Bild 7 aus.<\/p>\n Bild 7: Ergebnis der Abfrage<\/span><\/b><\/p>\n In den vier hinteren Feldern haben wir jeweils die beiden zusammengehörenden Felder ausgewertet, und zwar in der Form, dass wir mit einem Ausdruck wie etwa für das erste Feld Nz([Tabelle1])=Nz([MSysObjects].[Name]) <\/b>ermitteln, ob die beiden Tabellennamen übereinstimmen. Dies geschieht nur, wenn die Tabelle sowohl im entsprechenden Feld der Tabelle tblKonfigurationen <\/b>als auch in einem Datensatz der Tabelle MSysObjects <\/b>enthalten ist. In diesem Fall liefert der genannte Ausdruck dann den Wert -1<\/b>, sonst den Wert 0<\/b>. Enthalten alle der letzten vier Spalten den Wert -1<\/b>, sind die Tabellen der Konfiguration in der Host-Datenbank enthalten, sonst nicht. Zusammenfassend könnten wir also sagen, dass die Konfiguration zur Datenbank passt, wenn das Produkt der letzten vier Spalten nicht 0 <\/b>ist. Zusammenfasst brauchen wir also nur den folgenden Ausdruck in einem einzelnen Feld mit dem Wert 0 <\/b>zu vergleichen, um zu prüfen, ob die Konfiguration nutzbar ist:<\/p>\n Dies müssen wir nun noch mit der Tabelle verheiraten, die als Datenherkunft für das Formular und als Datensatzherkunft für das Kombinationsfeld cboKonfigurationen <\/b>herhält.<\/p>\n Genau genommen bearbeiten wir die Abfrage aus der obigen Abbildung einfach weiter, indem wir alle Felder außer KonfigurationID <\/b>entfernen, die übrigen Felder der Tabelle tblKonfigurationen <\/b>hinzufügen und noch ein Feld, das wie in Bild 8 aussieht und den obigen Ausdruck als Inhalt hat. Speichern Sie diese Abfrage unter dem Namen qryKonfigurationen<\/b>.<\/p>\n Bild 8: Neue Abfrage für die Datenherkunft des Hauptformulars<\/span><\/b><\/p>\n Nun tragen Sie diese Abfrage für die Eigenschaft Datenherkunft <\/b>des Formulars frmTabellen <\/b>ein sowie für Eigenschaft Datensatzherkunft <\/b>des Kombinationsfeldes cboKonfigurationen <\/b>des gleichen Formulars. Damit sind wir zumindest einmal so weit, was den Einsatz und den Test in der Add-In-Datenbank selbst angeht. Allerdings stammen die vier Instanzen der Tabelle MSysObjects <\/b>in der Abfrage ja aus der jeweiligen Host-Tabelle, weshalb uns die Abfrage in der aktuellen Form nicht für den Einsatz als Add-In weiterhilft.<\/p>\n Wir können hier mit dem IN<\/b>-Statement von Access-SQL arbeiten, welches beispielsweise erlaubt, Daten von Tabellen aus anderen Datenbanken zu ermitteln. Das gelingt beispielsweise so:<\/p>\n Dummerweise müssten wir den Namen der Datenbank aber dynamisch eintragen, je nachdem, von welcher Host-Datenbank aus das Add-In geöffnet wird. Und eine Möglichkeit, den Datenbankpfad zur Laufzeit in die IN<\/b>-Klausel der Abfrage zu schreiben, ist uns nicht bekannt. Also übernehmen wir diese Aufgabe einfach in das Form_Load<\/b>-Ereignis und weisen die Datenherkunft des Formulars und die Datensatzherkunft des Kombinationsfeldes dort dynamisch zu, indem wir an den entsprechenden Stellen die Funktion CurrentDb.Name <\/b>einsetzen. Die daraus resultierende SQL-Anweisung wollten wir dann der Eigenschaft Datenherkunft<\/b> des Formulars und Datensatzherkunft <\/b>des Kombinationsfeldes cboKonfigurationen <\/b>zuweisen. Dies gelang auch – allerdings ist das Ergebnis dieser Abfrage mit mehreren LEFT JOIN<\/b>-Operationen natürlich nicht mehr aktualisierbar. Also haben wir die Abfrage erneut umgebaut, indem wir sie in eine Unterabfrage für eine Hauptabfrage wie die folgende gepackt haben:<\/p>\n Die IN<\/b>-Abfrage ist natürlich entsprechend umfangreich. Insgesamt mussten wir die Prozedur Form_Load <\/b>wie in Listing 3 abgebildet umbauen.<\/p>\nStartfunktion definieren<\/h2>\n
Function <\/span>Autostart()\r\n DoCmd.OpenForm \"frmTabellen\"\r\nEnd Function<\/span><\/pre>\nAnwendungseigenschaften anpassen<\/h2>\n
![\"ändern](\"..\/fileadmin\/_temp_\/2017_02\/pic_1083_004.png\")
<\/p>\nDatenbanktyp ändern<\/h2>\n
Add-In registrieren<\/h2>\n
![\"Add-In-Manager](\"..\/fileadmin\/_temp_\/2017_02\/pic_1083_003.png\")
<\/p>\nErster Start<\/h2>\n
![\"Fehler](\"..\/fileadmin\/_temp_\/2017_02\/pic_1083_005.png\")
<\/p>\nWarnung: Code im Add-In ändern<\/h2>\n
\n
Zugriff auf Datenherkünfte von Tabellen, die sich nicht im Add-In befinden<\/h2>\n
Private Sub <\/span>UnterformulareAktualisieren()\r\n ...\r\n Me!sfmTabelle4.Form.RecordSource = Nz(Me!cboTabellen4)\r\n ...\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>UnterformulareAktualisieren()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst1 As <\/span>DAO.Recordset\r\n Dim <\/span>rst2 As <\/span>DAO.Recordset\r\n Dim <\/span>rst3 As <\/span>DAO.Recordset\r\n Dim <\/span>rst4 As <\/span>DAO.Recordset\r\n Set<\/span> db = CurrentDb\r\n If <\/span>Not<\/span> IsNull(Me.cboTabellen4) Then<\/span>\r\n Set<\/span> rst4 = db.OpenRecordset(Me!cboTabellen4, _\r\n dbOpenDynaset)\r\n Me!cboFremdschluessel4.RowSource = -_\r\n Nz(Me!cboTabellen4)\r\n Set<\/span> Me!sfmTabelle4.Form.Recordset = rst4\r\n UnterformularEinstellen Me!sfmTabelle4.Form\r\n End If<\/span>\r\n \r\n ...\r\nEnd Sub<\/span><\/pre>\nWeitere Recordsets zuweisen<\/h2>\n
![\"Das](\"..\/fileadmin\/_temp_\/2017_02\/pic_1083_006.png\")
<\/p>\nSELECT MSysObjects.Name FROM MSysObjects WHERE (((MSysObjects.Name) Not<\/span> Like ''MSys*'' \r\nAND (MSysObjects.Name) Not<\/span> Like ''~*'' And (MSysObjects.Name) Not<\/span> Like ''f_*'') \r\nAND ((MSysObjects.Type) In (1,4,5,6))) ORDER BY MSysObjects.Name;<\/pre>\nPrivate Sub <\/span>Form_Load()\r\n Dim <\/span>strBezeichnung As String<\/span>\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>lngKonfigurationID As Long<\/span>\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT MSysObjects.Name FROM MSysObjects WHERE (((MSysObjects.Name) Not<\/span> Like \" _\r\n \"''MSys*'' And (MSysObjects.Name) Not<\/span> Like ''~*'' And (MSysObjects.Name) Not<\/span> Like ''f_*'') AND ((MSysObjects.Type) \" _\r\n \"In (1,4,5,6))) ORDER BY MSysObjects.Name;\", dbOpenDynaset)\r\n Set<\/span> Me!cboTabellen1.Recordset = rst\r\n Set<\/span> Me!cboTabellen2.Recordset = rst\r\n Set<\/span> Me!cboTabellen3.Recordset = rst\r\n Set<\/span> Me!cboTabellen4.Recordset = rst\r\n ... \r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>cboTabellen1_AfterUpdate()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset(Me!cboTabellen1, dbOpenDynaset)\r\n Me!cboPrimaerschluessel1.RowSource = Nz(Me!cboTabellen1)\r\n Me!cboPrimaerschluessel1 = Null\r\n Me!cboPrimaerschluessel1.SetFocus\r\n Me!cboPrimaerschluessel1.Dropdown\r\n Set<\/span> Me!sfmTabelle1.Form.Recordset = rst\r\n'' Me!sfmTabelle1.Form.RecordSource = Nz(Me!cboTabellen1)\r\n UnterformularEinstellen Me!sfmTabelle1.Form\r\nEnd Sub<\/span><\/pre>\nLetzte Aufgabe: Konfigurationen identifizieren<\/h2>\n
Konfigurationen mit Tabellen der Host-Datenbank abgleichen<\/h2>\n
![\"Abfrage,](\"..\/fileadmin\/_temp_\/2017_02\/pic_1083_007.png\")
<\/p>\n![\"Ergebnis](\"..\/fileadmin\/_temp_\/2017_02\/pic_1083_008.png\")
<\/p>\n(Nz([Tabelle1])=Nz([MSysObjects].[Name]))\r\n*(Nz([Tabelle2])=Nz([MSysObjects_3].[Name]))\r\n*(Nz([Tabelle3])=Nz([MSysObjects_2].[Name]))\r\n*(Nz([Tabelle4])=Nz([MSysObjects_1].[Name]))<\/pre>\n
![\"Neue](\"..\/fileadmin\/_temp_\/2017_02\/pic_1083_009.png\")
<\/p>\nSELECT * FROM tblTest IN (''c:\\Testdatenbank.accdb'')<\/pre>\nSELECT * FROM tblKonfigurationen \r\nWHERE KonfigurationID IN (SELECT ...)<\/pre>\n
Private Sub <\/span>Form_Load()\r\n Dim <\/span>strBezeichnung As String<\/span>\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>strSQL As String<\/span>\r\n Dim <\/span>lngKonfigurationID As Long<\/span>\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n strSQL = \"SELECT * FROM tblKonfigurationen WHERE KonfigurationID IN (SELECT KonfigurationID " _\r\n & "FROM (((tblKonfigurationen LEFT JOIN [;database=\" & CurrentDb.Name & \"].[MSysObjects] " _\r\n & "ON tblKonfigurationen.Tabelle1 = MSysObjects.Name) LEFT JOIN [;database=\" & CurrentDb.Name _\r\n & \"].[MSysObjects] AS MSysObjects_3 ON tblKonfigurationen.Tabelle2 = MSysObjects_3.Name) " _\r\n & " LEFT JOIN [;database=\" & CurrentDb.Name & \"].[MSysObjects] AS MSysObjects_2 " _\r\n & " ON tblKonfigurationen.Tabelle3 = MSysObjects_2.Name) LEFT JOIN [;database=\" & CurrentDb.Name _\r\n & \"].[MSysObjects] AS MSysObjects_1 ON tblKonfigurationen.Tabelle4 = MSysObjects_1.Name " _\r\n & " WHERE (Nz([Tabelle1])=Nz([MSysObjects].[Name])) *(Nz([Tabelle2])=Nz([MSysObjects_3].[Name])) " _\r\n & " *(Nz([Tabelle3])=Nz([MSysObjects_2].[Name])) *(Nz([Tabelle4])=Nz([MSysObjects_1].[Name])) <> 0);\"\r\n Me.RecordSource = strSQL\r\n Me!cboKonfiguration.RowSource = strSQL\r\n ...\r\nEnd Sub<\/span><\/pre>\n