Mit Access-Add-Ins lassen sich eine Menge Funktionen für Access nachrüsten. Einige Anwendungen produzieren dabei sogar Daten, die im Add-In gespeichert und später wieder bereitgestellt werden. Eigentlich kein Problem – Sie können von einem Add-In aus sowohl auf die Tabellen der Host-Datenbank zugreifen als auch auf die Tabellen in der Add-In-Datenbank selbst. Aber was ist, wenn Sie eine neue Version des Add-Ins liefern, der Benutzer jedoch die bereits damit erstellten Daten weiter nutzen möchte Die Lösung ist ein Backend. Die Installation eines Add-Ins plus Backend-Datenbank ist jedoch komplizierter als ohne. Wie dies einfach gelingt, zeigt dieser Beitrag.
Access-Add-Ins lassen sich vergleichbar einfach installieren: Sie bringen die .mda– oder .accda-Datei zunächst irgendwo auf der lokalen Festplatte unter. Dann öffnen Sie Access, starten den Add-In-Manager (unter Access 2003 und älter mit dem Menübefehl Extras|Add-Ins|Add-In-Manager oder unter Access 2007 und jünger mit dem Ribbon-Eintrag Datenbank-Tools|Add-Ins|Add-In-Manager) und wählen dort den Befehl Neues hinzufügen (kann je nach Version variieren) aus. Im folgenden Dialog wählen Sie die .mda– oder .accda-Datei aus und sorgen so dafür, dass Access diese Datei in das Add-In-Verzeichnis des Systems speichert und einige Einträge in der Registry anlegt, die Access beim Start Informationen über das neue Add-In liefern.
Nun tritt der bereits in der Einleitung erwähnte Fall ein, dass ein Add-In nicht nur aus der eigentlichen Add-In-Datenbank besteht, sondern zusätzlich noch aus einem Backend. Dieses können Sie zwar problemlos etwa in einer .zip-Bibliothek mitliefern, aber wie gelangt die Backend-Datei in das Add-In-Verzeichnis, damit das Add-In-Frontend dieses schnell und zuverlässig etwa per Referenz über den aktuellen Datenbankordner (CurrentProject.Path) finden kann Da gibt es mehrere Möglichkeiten:
- Sie teilen dem Benutzer gleich zu Beginn mit, dass er Frontend und Backend direkt in das Add-In-Verzeichnis von Access kopiert und die dortige Version des Frontends mit dem Add-In-Manager installiert. Nachteil: Je nach Betriebssystem-Version und Benutzer variiert der Pfad zum Add-In-Verzeichnis und der Benutzer muss erst suchen.
- Sie lassen den Benutzer die beiden Dateien an beliebiger Stelle speichern, installieren das Add-In mit dem Add-In-Manager und fordern den Benutzer beim ersten Start des Add-Ins unter Angabe des Add-In-Verzeichnisses (das sich ja beim Start des Add-Ins mit Codeproject.Path ermitteln lässt) auf, die Backend-Datenbank ins Add-In-Verzeichnis zu kopieren. Ist vielleicht etwas benutzerfreundlicher als die erste Variante, aber nicht optimal.
- Sie lassen den Add-In-Manager komplett aus dem Spiel und erstellen mit einem Setup-Tool Ihrer Wahl ein einfaches Setup, dass beide Dateien in das Add-In-Verzeichnis kopiert und die benötigten Registry-Einträge vornimmt. Auch hier muss man allerdings erst das Add-In-Verzeichnis programmatisch ermitteln beziehungsweise durch den Benutzer auswählen lassen.
- Letzte Variante, die in diesem Beitrag vorgestellt wird: Sie geben einfach nur eine Add-In-Datenbank weiter und speichern in einer Tabelle dieser Datenbank die Backend-Datei. Das Add-In kann dann ohne Kenntnis des Add-In-Verzeichnisses und weiteres Zutun des Benutzers über den Add-In-Manager installiert werden. Beim Starten prüft das Add-In dann, ob die Backend-Datenbank bereits im gleichen Verzeichnis, also im Add-In-Verzeichnis, liegt. Ist dies nicht der Fall, wird das Backend aus der Tabelle in das Add-In-Verzeichnis kopiert. Danach werden die Tabellen verknüpft und das Add-In kann seine Arbeit aufnehmen.
Speichern eines Backends in einer Add-In-Datenbank
Das Backend soll in einem OLE-Feld einer Tabelle der Add-In-Datenbank gespeichert werden. Dazu legen Sie zunächst eine Tabelle an, die nur ein Primärschlüsselfeld und ein Feld namens Backend mit dem Datentyp OLE-Objekt enthält (s. Bild 1).
Bild 1: Tabelle zum Speichern des Backends
Nun benötigen Sie zunächst eine Funktion, die eine beliebige Backend-Datenbank in das OLE-Feld der Tabelle tblBackend schreibt. Diese Funktion finden Sie in Listing 1. Die Funktion erwartet als einzigen Parameter den Namen der Backend-Datenbank. Der Aufruf dieser Prozedur könnte also beispielsweise wie folgt aussehen:
Public Sub BackendSpeichern()
If SaveBackendToOLEField(CurrentProject.Path & "\Addin_BE.mda") = True Then
MsgBox "Backend erfolgreich gespeichert."
Else
MsgBox "Backend wurde nicht hinzugefügt."
End If
End Sub
Listing 1: Einfügen der Backend-Datenbank in das OLE-Feld der Tabelle tblBackend
Public Function SaveBackendToOLEField(strFilename As String) As Long
Dim db As DAO.Database
Dim rst As DAO.Recordset
Dim lngFileID As Long
Dim Buffer() As Byte
Dim lngFileLen As Long
Dim strSQL As String
On Error GoTo SaveBackendToOLEField_Err
Set db = CurrentDb
db.Execute "DELETE FROM tblBackend", dbFailOnError
strSQL = "SELECT Backend FROM tblBackend"
Set rst = db.OpenRecordset(strSQL, dbOpenDynaset)
If Dir(strFilename) = "" Then
MsgBox "Die Datei ''" & strFilename & "'' existiert nicht."
Exit Function
End If
rst.AddNew
lngFileID = FreeFile
Open strFilename For Binary Access Read Lock Read Write As lngFileID
lngFileLen = LOF(lngFileID)
ReDim Buffer(lngFileLen)
rst!Backend = Null
Get lngFileID, , Buffer
rst!Backend.AppendChunk Buffer
rst.Update
SaveBackendToOLEField = True
SaveBackendToOLEField_Exit:
On Error Resume Next
Close lngFileID
rst.Close
Set rst = Nothing
Set db = Nothing
Exit Function
SaveBackendToOLEField_Err:
SaveBackendToOLEField = Err.Number
Resume SaveBackendToOLEField_Exit
End Function
Die Funktion selbst öffnet die Datenbankdatei für den binären Zugriff und schreibt ihren Inhalt in das Feld Backend der Tabelle tblBackend. Ein eventuell bestehender Datensatz wird zuvor gelöscht, anschließend öffnet die Funktion eine neue Datensatzgruppe auf Basis der Tabelle tblBackend. Vor dem Anlegen eines neuen Datensatzes erfolgt noch die Prüfung, ob die angegebene Datenbankdatei überhaupt im Dateisystem vorliegt – falls nicht, wird die Prozedur beendet. In der Regel sollte diese Datei jedoch vorhanden sein, sodass im nächsten Schritt ein neuer Datensatz in der Tabelle tblBackend angelegt wird. Die Dateinummer für die Referenz auf die angegebene Datei wird in der Variablen lngFileID gespeichert, anschließend wird die Datei geöffnet. Die Länge beziehungsweise Größe der Datei vermerkt die Funktion in der Variablen lngFileLen, mit der auch gleich ein entsprechendes Byte-Array als Zwischenspeicher vor dem Eintragen in der Tabelle dimensioniert wird. Die Get-Methode füllt den Dateiinhalt in das Byte-Array Buffer, von wo aus die Datei mit der AppendChunk-Methode gleich in das Feld Backend der Tabelle tblBackend geschrieben wird. Danach sorgt die Update-Methode für das Speichern dieses Datensatzes. Enthält das Feld Backend anschließend wie in Bild 2 den Wert Long Binary Daten, scheint alles funktioniert zu haben.
Bild 2: Tabelle zum Speichern des Backends in der Datenblattansicht
Backend exportieren
Eine zweite Funktion soll die im Feld Backend der Tabelle tblBackend gespeicherte Datei wieder im Dateisystem speichern, und zwar unter dem mit dem Parameter strFilename angegebenen Dateinamen. Das Basisverzeichnis entspricht dem aktuellen Verzeichnis der Add-In-Datei, das hier mit CodeProject.Path ermittelt wird. Warum CodeProject.Path und nicht CurrentProject.Path
Ganz einfach: Weil diese Funktion später von der Add-In-Datenbank aus aufgerufen werden soll, während diese von der Host-Datenbank aus als Add-In geöffnet ist.
Sind Host- und Add-In-Datenbank aktiv, referenzieren Sie mit CurrentProject die Host-Datenbank und mit CodeProject die Add-In-Datenbank. Wenn Sie hier CurrentProject.Path verwenden, würde das Backend des Add-Ins im Verzeichnis der Host-Datei gespeichert, von der aus das Add-In geöffnet wurde.
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