Frontends aktualisieren

Wenn Sie den Benutzern eine Access-Datenbank in einer Mehrbenutzerumgebung bereitstellen, erfordert dies wesentlich mehr Arbeit als eine Einzelplatzanwendung. Beispielsweise wäre da die Aufteilung in eine Backend- und mehrere Frontenddatenbanken, die Pflege von Front- und Backend etwa in Form des regelmäßigen Komprimierens zur Vermeidung eines Aufblähens der Datenbanken und mehr. Dieser Artikel stellt grundlegende Techniken zu diesen Anforderungen vor.

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 1508_FrontBackend.zip.

Mehrbenutzerumgebung

Wenn eine Access-Datenbank von mehreren Nutzern gleichzeitig in Betrieb ist, so sieht das übliche System folgendermaßen aus: Auf den Arbeitsstationen liegen die Frontend-Datenbanken, die für die Anwenderoberfläche verantwortlich sind. Sie werden durch Doppelklick auf die accdb-Datei oder über eine Desktop-Verknüpfung auf sie in Access gestartet.

In diesem Frontend befinden sich jedoch nicht die gemeinsam zu bearbeitenden Daten, denn dafür ist genau eine Backend-Datei zuständig, die die entsprechenden Tabellen enthält. Sie liegt in der Regel auf einem File-Server in einem Verzeichnis, auf das alle Benutzer Lese- und Schreibrechte haben. Allerdings reicht auch das meist noch nicht aus, denn beim Komprimieren der Backenddatei wird eine temporäre Datei im Verzeichnis angelegt, die alte gelöscht und sie anschließend umbenannt. Damit sind Verwaltungsrechte auf das Verzeichnis nötig, also die Erlaubnis für das Löschen und Erzeugen von Dateien.

Die Tabellen dieses Backends werden nun in die Frontends verknüpft. Auf diese verknüpften Tabellen bauen die Formulare und Berichte der Anwendung auf.

Einmal eingerichtet könnte mit diesem System in aller Ruhe gearbeitet werden, wären da nicht ein paar Fallstricke. Sowohl Backend, wie Frontend blähen sich im Betrieb mit der Zeit auf. Deshalb ist das regelmäßige Komprimieren beider zu empfehlen, wenn nicht die Performance irgendwann einbrechen und die Anwender über Kaffeepausen beim Bearbeiten ihrer Daten klagen sollen. Auch die Gefahr von Datenkorruption nimmt zu, wenn das Komprimieren nie geschieht.

Und dann bleibt es selten bei der Urfassung einer Datenbank. Weiterentwicklung ist an der Tagesordnung. Mit jeder neuen Version stehen Sie vor der Aufgabe, das neue Frontend auf die Arbeitsstationen zu verteilen.

Das kann man manuell erledigen, falls man Vorort weilt, aber komfortabler wäre doch eine automatisierte Lösung. Dann können Sie das neue Frontend einfach auf einen File-Server legen, auf den Sie unter Umständen sogar per VPN Fernzugriff haben.

Blöd nur, dass dann die Pfade der verknüpften Tabellen im Frontend nun nicht mehr stimmen. Auf Ihrem Entwicklerrechner haben Sie wahrscheinlich ganz andere Verzeichnisstrukturen, als die Anwender in der Firma. Also müssen in den Frontends die Tabellen neu mit dem Backend verknüpft werden, was wiederum eine Aufgabe ist, die Sie besser nicht dem Anwender überlassen. Auch das sollte automatisch im Hintergrund vor sich gehen.

Damit stellen sich diese vier Grundanforderung:

  • Das Frontend soll automatisch auf die Arbeitsrechner verteilt werden
  • Das Backend soll automatisch regelmäßig komprimiert werden
  • Das Frontend ebenfalls
  • Die Backend-Tabellen sollen automatisch im Frontend verknüpft und aktualisiert werden

Schauen wir uns dazu einige einfach gehaltene Lösung an.

Frontend aktualisieren

Im Prinzip geht es dabei um nichts anderes, als Ihr Entwickler-Frontend als Datei auf die einzelnen Rechner zu kopieren. Mancher sieht hier eine Versionierung vor. Das Kopieren geschähe demnach nur, wenn eine neuere Version des Frontends vorläge. Dafür gibt es aber wenig plausible Gründe. Am Einfachsten ist es, das Kopieren schlicht von einem Skript durchführen zu lassen, welches entweder beim Starten der Anwendung angestoßen wird, oder im Autostart-Ordner der Rechner liegt, so dass es jeweils beim Anmelden am Rechner ausgeführt wird.

Wir entscheiden uns hier für die erste Lösung, weil das Frontend so auf Zuruf etwa auch mittags aktualisiert werden kann. Eigentlich reicht für diesen Zweck eine kurze Windows-Batch-Datei aus. Da wir uns jedoch in der Ausgabe 04/2015 von AccessBasics bereits mit VB-Script auseinandersetzten, verwenden wir diese Sprache auch an dieser Stelle. Mit VB-Script hat man etwa mehr Möglichkeiten zur Kontrolle der Vorgänge und kann eine Fehlerbehandlung vorsehen.

Das Kopier-Skript finden Sie in Listing 1. Speichern Sie den Text als Datei unter dem Namen copy_frontend.vbs im Verzeichnis der Datenbank. Leider gibt es unter VB-Script keine direkte Funktion zum Ermitteln des aktuellen Verzeichnisses. Mit einem Trick gelingt jedoch auch dies. ScriptFullName ist eine Eigenschaft, die den Dateinamen des aktuell ausgeführten Skripts selbst wiederspiegelt. Damit ist der Pfad ebenfalls enthalten. über die InstrRev-Funktion und Left wird das Verzeichnis aus dem Dateipfad herausgeschnitten. Damit steht das Zielverzeichnis für den Kopiervorgang in der Variablen sPathTarget bereit. In der Demo zum Beitrag ist das Verzeichnis, in dem sich das Entwickler-Frontend befindet, durch den Unterordner FileShare simuliert. sPathSource wird entsprechend gebildet. In natura setzten Sie hier eher hartkodiert den Pfad zum Server-Verzeichnis ein.

sScriptFile = WScript.ScriptFullName 
n = InstrRev(sScriptFile,"\")
sPathTarget = Left(sScriptFile,n)
sPathSource = sPathTarget & "FileShare"
sFileSource = sPathSource & "\1508_Frontend.accdb"
Set fso = CreateObject("Scripting.FileSystemObject")
If fso.FileExists(sFileSource) Then
    fso.CopyFile sFileSource, sPathTarget, True
    Msgbox "Info: Datenbank-Frontend aktualisiert."
End if

Listing 1: VBS-Script zum Aktualisieren des Frontends aus einem File Share

Zum Kopieren von Dateien müssen Sie unter VB-Script ein Shell-Objekt bemühen, wie es etwa im FileSystemObject vorliegt. Die Objektvariable fso nimmt es auf. Mit FileExists wird zunächst überprüft, ab das Entwickler-Frontend überhaupt vorhanden ist. Im Erfolgsfall übernimmt CopyFile dann letztendlich das Kopieren. Der Parameter Overwrite steht auf True, was bedeutet, dass eine eventuell vorhandene Datei gleichen Namens sang- und klanglos überschrieben wird. Der Erfolg der Aktion wird am Schluss über eine Messagebox quittiert. Diese Zeile können Sie natürlich löschen.

Frontend komprimieren und starten

Auch für diese Aufgabe steht ein VB-Script bereit. Das Problem ist ja, dass eine Datenbank per VBA nicht komprimiert werden kann. Das Komprimieren schließt zunächst die Datenbank, wodurch eine laufende Prozedur sofort abgebrochen würde. Aus diesem Grund hat Microsoft allen Methoden zum Komprimieren der aktuellen Datenbank einen Riegel vorgeschoben. Ergo muss das Frontend extern komprimiert werden.

Das Skript in Listing 2 speichern Sie unter dem Namen startdb_compressed.vbs ebenfalls im Datenbankordner. ähnlich, wie im vorigen Skript, ermittelt die Routine zunächst den Pfad des Datenbankordners über ScriptFullName, um darüber den Namen der Frontend-Datei in sFile zu generieren.

sScriptFile = WScript.ScriptFullName 
n = InstrRev(sScriptFile,"\")
sPath = Left(sScriptFile,n)
sFile = sPath & "1508_Frontend.accdb"
Set fso = CreateObject("Scripting.FileSystemObject")
Set oDBEng = CreateObject("DAO.DbEngine.120")
If fso.FileExists(sPath & "tmp.accdb") Then
    Set f = fso.GetFile(sPath & "tmp.accdb")
    f.Delete
End if
oDBEng.CompactDatabase sFile, sPath & "tmp.accdb"
If fso.FileExists(sPath & "tmp.accdb") Then
    Set f = fso.GetFile(sFile)
    f.Delete
    Set f = fso.GetFile(sPath & "tmp.accdb")
    f.Name = "1508_Frontend.accdb"
End If
Set oShell = CreateObject("Shell.Application")
oShell.ShellExecute sFile

Listing 2: VBS-Script zum Komprimieren und Starten des Frontends

Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!
Hier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]:
Zur Bestellung ...
Danach greifen Sie sofort auf alle rund 400 Artikel unseres Angebots zu - auch auf diesen hier!
Oder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

Schreibe einen Kommentar