Frontends aktualisieren

Transkript

1 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 Seite 14

2 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 Access- Basics 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. 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 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. 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. 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. Seite 15

3 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" Set oshell = CreateObject("Shell.Application") oshell.shellexecute sfile Listing 2: VBS-Script zum Komprimieren und Starten des Frontends 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. Der Prozedur kann als Parameter der Ort der Backend-Datei in spath übergeben werden. Bleibt dies aus, so wird als Pfad für die Backend- Datei das Verzeichnis des Frontends angenommen, welches über CurrentProject.Path ermittelt wird. 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. Doch wie kommt man an den Namen der Backend-Datei selbst? Die Routine macht sich hier zunutze, dass in der TableDef-Eigenschaft Connect einer verknüpften Tabelle der volle Pfad zum Backend enthalten ist. Aus diesem wird der reine Dateiname extrahiert und in sbackend zwischengespeichert, wobei ihm hier das über spath gegebene Verzeichnis vorangestellt wird. In der Folge werden alle Tabellen des Frontends in einer Schleife auf die TableDefs-Auflistung durchlaufen, wobei aber nur jene berücksichtigt werden, die das Attribut dbattachedtable besitzen. Hier handelt es sich um verknüpfte Tabellen. Auf diese Weise werden alle lokalen Tabellen und die Systemtabellen ausgefiltert. Liegt eine verknüpfte Tabelle vor, so wird ihr Backend-Pfad über die Connect-Eigenschaft neu Seite 16

4 besetzt. Ein RefreshLink sichert ab, dass dies auch zum Tragen kommt. Nach Durchlaufen der Schleife sind alle verlinkten Tabellen neu mit dem Backend verknüpft, und als Funktionsergebnis wird ein True für den Erfolg der Aktion gesetzt. Backend komprimieren Führen Sie sich Listing 4 zu Gemüte. Die Funktion BackendKomprimieren realisiert Ähnliches, wie das VB- Script zum Komprimieren des Frontends, nur dass hier VBA zum Einsatz kommt und das Backend Ziel des Vorgangs ist. Im Parameter sfile kann dezidiert, aber optional, die Backend-Datei angegeben werden. Lässt man die Angabe weg, so ermittelt die Routine wieder über das TableDef-Objekt der Tabelle tblkunden eine beliebige verknüpfte Tabelle kommt hier in Betracht und deren Connect- Eigenschaft selbständig den Pfad. Bevor nun wieder die CompactDatabase-Methode für dieses Backend aufgerufen wird, muss erst sichergestellt sein, dass das Backend sich nicht schon anderweitig im Zugriff befindet. Das dürfte jedoch in einer Mehrbenutzerumgebung eher die Regel, denn die Ausnahme, sein. Ein Backend, welches sich bereits im Zugriff befindet, kann nicht komprimiert werden. Die Backend-Datei wird also mit der Open-Anweisung testweise für den binären Zugriff und im Modus Write geöffnet. Schlägt das fehl, so springt 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) sbackend = spath & sbackend For Each tdf In dbs.tabledefs If (tdf.attributes And dbattachedtable) <> 0 Then tdf.connect = ";DATABASE=" & sbackend tdf.refreshlink BackendVerknuepfen = True Next tdf Exit Function Fehler: MsgBox Err.description, vbcritical End Function Listing 3: Routine zum Neuverknüpfen der Tabellen im Backend die Routine in die Fehlerbehandlung und beendet sich. Dass die Datei auf diese Weise geöffnet werden kann, ist indessen noch kein sicheres Indiz für Komprimierfähigkeit. Durch das testweise Setzen des Dateiattributs vbnormal (SetAttr- Anweisung) kann ermittelt werden, ob das Backend aus unerfindlichem Grund noch schreibgeschützt ist. Erst, wenn beide Tests erfolgreich waren, geht es an das Komprimieren. Vielleicht stellt sich die Frage, wann diese Funktion im Frontend aufgerufen werden sollte. Das ist jedoch unkritisch. Legen Sie sie auch hier in ein AutoExec-Makro. Sollte das Backend bereits von einem anderen Anwender geöffnet sein, so beendet sich die Routine ja automatisch. Nehmen Sie dann auch besser die MsgBox aus der Fehlerbehandlung heraus. Nun wird das Backend ganz einfach vom ersten User, der sich morgens an die Arbeit macht und sein Frontend öffnet, komprimiert. Bei allen weiteren Anwendern bleibt die Funktion ohne Folgen. Die Funktionen zum Neuverknüpfen und zum Komprimieren rufen Sie hintereinander am besten aus einer gesonderten Prozedur aus auf, wie in der Beispieldatenbank in der Funktion TestBackendVerknuepfen geschehen, welche zusätzlich einen String mit dem Resultat der Vorgänge zurückgibt. Seite 17

5 ACCess basics Zusammengefasst Auf den Arbeitsrechnern legen Sie die Dateien so an, wie in Bild 1. Die Unterverzeichnisse allerdings werden so nicht benötigt und stehen für den Ort des Entwickler-Frontends, sowie des Backends, welche sich wohl auf einem Server im Netzwerk befinden werden. Die Verknüpfung Datenbank starten ziehen Sie auf den Desktop des Users. Wenn Sie das Frontend einer Weiterentwicklung oder Fehlerkorrektur unterzogen haben, müssen Sie nun weiter nichts tun, als es im FileShare zu überschreiben. Alles Weitere geschieht automatisch. Doch Vorsicht! Benennen Sie die alte Frontend- Datei besser um, statt sie zu löschen etwa in 1508_frontend.accdb.bak. Nicht selten haben Sie im Rausch der Programmierung etwas übersehen, was den Anwendern Kopfschmerzen bereitet. Dann löschen Sie die neue Version wieder und benennen das Backup einfach wieder zurück. Eine Rund- an die Betroffenen mit der Aufforderung, die Datenbank über die Verknüpfung neu zu starten, stellt sie dann zunächst zufrieden. Function BackendKomprimieren(Optional sfile As String) As Boolean Dim dbs As Database Dim tdf As TableDef Dim spath As String Dim n As Long On Error GoTo Fehler Set dbs = CurrentDb If Len(sFile) = 0 Then Set tdf = dbs.tabledefs("tblkunden") sfile = tdf.connect If Left(sFile, 10) = ";DATABASE=" Then sfile = Mid(sFile, 11) Else If Right(sFile, 1) <> "\" Then sfile = sfile & "\" Open sfile For Binary Access Write As #1 Close #1 SetAttr sfile, vbnormal n = InStrRev(sFile, "\") spath = Left(sFile, n) sfile = Mid(sFile, n + 1) DBEngine.CompactDatabase spath & sfile, spath & "tmp.accdb" DoEvents If Len(Dir(sPath & "tmp.accdb")) > 0 Then Kill spath & sfile Name spath & "tmp.accdb" As spath & sfile BackendKomprimieren = (Len(Dir(sPath & sfile)) > 0) Exit Function Fehler: MsgBox Err.description, vbcritical End Function Listing 4: Routine zum Komprimieren des Backends Hier wurden nur die Basics dargestellt. Andere und andere Techniken sind denkbar. Aber immerhin ist die Problemlage im Mehrbenutzerbetrieb einmal klargestellt. Bild 1: Das Datenbankverzeichnis mit den benötigten Daten und Unterordnern Seite 18