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.
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.
Tabelle USysRegInfo anlegen
Aufmerksame Leser unseres Magazins wissen, dass eine Tabelle namens USysRegInfo 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.
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 aufgerufen werden soll.
Bild 1: Die Tabelle USysRegInfo
Die zweite enthält das Verzeichnis, in dem das Add-In gespeichert sein wird. |ACCDIR wird beim Registrieren automatisch durch das Add-In-Verzeichnis ersetzt.
Startfunktion definieren
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 aufrufen.
Die Funktion legen wir in einem neuen Standardmodul namens mdlAddIn an:
Function Autostart() DoCmd.OpenForm "frmTabellen" End Function
Anwendungseigenschaften anpassen
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, die Firma und der Kommentar (s. Bild 2).
Bild 2: ändern der Eigenschaften der Access-Anwendung
Datenbanktyp ändern
Damit die Add-In-Datenbank als solche erkannt wird, ändern Sie die Dateiendung der Datenbank von .accdb auf .accda.
Add-In registrieren
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 aus. Klicken Sie auf die Schaltfläche Neues hinzufügen…, um einen Datei öffnen-Dialog zu öffnen und die .accda-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.
Bild 3: Add-In-Manager von Access
Erster Start
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 klicken und sich den Fehler ansehen – hierzu folgt später eine Warnung!
Bild 4: Fehler beim Versuch, das neue Add-In zu starten
Schauen wir zunächst auf den Fehler: Access kann die Tabelle tblArtikel, die als Datenherkunft des Formulars angegeben werden soll, nicht finden. Das hat normalerweise den Grund, dass keine solche Tabelle in der Datenbank enthalten ist.
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.
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! Die Tabelle tblArtikel 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.
Warnung: Code im Add-In ändern
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.
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.
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:
- Sie ändern direkt die Add-In-Datenbank im Add-In-Verzeichnis.
- Sie ändern die Originaldatenbank und kopieren diese nach dem ändern jeweils über die Version im Add-In-Verzeichnis.
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 -, müssen Sie das Add-In auch neu registrieren.
Zugriff auf Datenherkünfte von Tabellen, die sich nicht im Add-In befinden
Die Zeile, die den obigen Fehler ausgelöst hat, befindet sich in der folgenden Prozedur:
Private Sub UnterformulareAktualisieren() ... Me!sfmTabelle4.Form.RecordSource = Nz(Me!cboTabellen4) ... End Sub
Gibt es eine Alternative zum Zuweisen des Namens der Tabelle zur Eigenschaft RecordSource des Unterformulars Wir könnten versuchen, ein Recordset auf Basis dieser Tabelle zu erstellen und dieses der Eigenschaft Recordset des Unterformulars zuweisen. Dazu benötigen wir zunächst eine Database-Variable und jeweils eine Recordset-Variable für die vier Unterformulare. Die Database-Variable füllen wir wie üblich mit der Funktion CurrentDb.
Den Recordset-Variablen weisen wir dann mit der OpenRecordset-Methode das Recordset auf Basis der im entsprechenden Kombinationfeld festgelegten Tabelle zu. Schließlich bekommt die Recordset-Eigenschaft der vier Unterformulare jeweils das entsprechende Recordset zugewiesen – hier die gekürzte Fassung der geänderten Prozedur:
Private Sub UnterformulareAktualisieren() Dim db As DAO.Database Dim rst1 As DAO.Recordset Dim rst2 As DAO.Recordset Dim rst3 As DAO.Recordset Dim rst4 As DAO.Recordset Set db = CurrentDb If Not IsNull(Me.cboTabellen4) Then Set rst4 = db.OpenRecordset(Me!cboTabellen4, _ dbOpenDynaset) Me!cboFremdschluessel4.RowSource = -_ Nz(Me!cboTabellen4) Set Me!sfmTabelle4.Form.Recordset = rst4 UnterformularEinstellen Me!sfmTabelle4.Form End If ... End Sub
Mit dieser änderung öffnet sich das Formular zumindest schon einmal fehlerfrei.
Aber warum gelingt dies nun so reibungslos Greifen wir mit den Recordsets auf Basis des mit CurrentDb gelieferten Database-Objekts nicht auch auf die Tabellen der Add-In-Datenbank zu Genau das geschieht nicht: CurrentDb 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 die Funktion CodeDb nutzen. Diese liefert einen Verweis auf das Database-Objekt der Add-In-Datenbank.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo