Home > Artikel > Ausgabe 8/2015 > Frontends aktualisieren

Frontends aktualisieren

Achtung: Sie sind nicht angemeldet. Wenn Sie Abonnent sind und sich anmelden, lesen Sie den kompletten Artikel, laden das PDF herunter oder probieren die Beispieldatenbank aus (sofern vorhanden).

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 & "󠾤_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

Für das Komprimieren benötigen Sie nicht zwingend Access als Anwendung. Es reicht dafür die ACE-Engine aus. Sie können eine Instanz dieser über CreateObject und die Klassenbezeichnung DAO.DbEngine.120 produzieren. Die Methode CompactDatabase des Engine-Objekts komprimiert und repariert eine Access-Datenbankdatei. Als Parameter erwartet sie dabei den Pfadnamen der ACCDB-Datei und die Angabe einer Zieldatei, die das komprimierte Resultat aufnimmt. Dass für beide Parameter nicht derselbe Dateiname infrage kommt, ist irgendwie logisch. Die Zieldatei nennt sich hier darum tmp.accdb. Nach Ausführung der Methode liegen nun zwei Dateien im Verzeichnis: die tmp-Datei und die Originaldatei.

Also muss die alte zunächst gelöscht werden, um anschließend der tmp-Datei wieder den Originalnamen zu geben. Beides erledigt wieder das FileSystemObject über die Methode Delete auf das über GetFile erhaltene File-Objekt und über die Name-Eigenschaft der tmp-Datei, was einem Umbenennen gleichkommt.

Damit ist der Komprimiervorgang abgeschlossen und es kann an das Starten des Frontends gehen. Die ShellExecute-Methode des Shell.Application-Objekts macht es möglich. Sie findet selbst heraus, welche Anwendung für das Öffnen einer Datei zuständig ist und führt sie aus, wobei die eigentliche Datei ihr als Argument übergeben wird.

Damit haben wir zwei Komponenten beisammen, die extern außerhalb von Access ausgeführt werden. Sie können sie beide aus einer Batch-Datei startdb.bat heraus starten, die nur diese beiden Zeilen enthält:

copy_frontend.vbs

startdb_compressed.vbs

Legen Sie optional eine Verknüpfung auf diese Batch-Datei auf dem Desktop an, benennen sie Datenbank starten und stellen Sie in ihren Eigenschaften ein, dass das Fenster des Batch-Skripts minimiert ausgeführt werden soll. Denn sonst sehen Ihre Anwender jedes Mal das schwarze Kommandozeilenfenster.

Backend-Tabellen neu verknüpfen

Für diese Aufgabe verwenden wir die Routine BackendVerknuepfen in Listing 3, die in der Beispieldatenbank beim Anklicken des Intro-Dialogs ausgelöst wird. Günstiger ist ihr Aufruf über ein AutoExec-Makro, in das Sie den Funktionsaufruf eingeben. So ist das Neuverknüpfen gleich beim Start der Datenbank gewährleistet.

Function BackendVerknuepfen(Optional sPath As String) As Boolean

     Dim dbs As Database

     Dim tdf As TableDef

     Dim sBackend As String

     Dim n As String

     

     On Error GoTo Fehler

     

     If Len(sPath) = 0 Then sPath = CurrentProject.Path

     If Right(sPath, 1) <> "\" Then sPath = sPath & "\"

     

     Set dbs = CurrentDb

     Set tdf = dbs.TableDefs("tblKunden")

     sBackend = tdf.Connect

     n = InStrRev(sBackend, "\")

     sBackend = Mid(sBackend, n + 1)

Sie haben das Ende des frei verfügbaren Teil dieses Artikels erreicht!

Wenn Sie mehr lesen und auf viele weitere Artikel zugreifen möchten, melden Sie sich als Abonnent unter Login an. Falls nicht, bestellen Sie doch einfach ein Jahresabonnement!