Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 4/2006.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Lernen Sie zwei Tools zur Vereinfachung der Verteilung von Datenbank-Frontends in Mehrbenutzerumgebungen kennen.

Techniken

Frontend/Backend

Voraussetzungen

Access 97 und höher

Frontend-Datenbanken aktualisieren

Karl Donaubauer, Wien

Access-Anwendungen in Mehrbenutzerumgebungen teilt man in Frontend- und Backend auf, wobei jeder Arbeitsplatz sein eigenes Frontend erhält. Einer der Vorteile der Aufteilung liegt darin, dass man Design und Funktion der Frontends problemlos ändern und diese austauschen kann, ohne das Backend anzutasten. Wie aber verteilt man danach das neue Frontend an alle Arbeitsstationen? Dieser Beitrag erklärt die Grundlagen und stellt zwei kostenlose Werkzeuge für diesen Zweck vor.

Backend und Frontend

Bei Access versteht man unter Backend eine .mdb-Datei, die nur die Tabellen enthält. Die Benutzeroberfläche und die Anwendungslogik in Form von Abfragen, Formularen, Berichten, Makros und VBA-Modulen finden sich als .mdb- oder .mde-Datei im Frontend.

Abb. 1: Backend und Frontends im Netz

Es greift über eine Verknüpfung auf die Tabellen im Backend zu. Bei Anwendungen im Netzwerk sollte jeder Benutzer sein eigenes, möglichst auf dem lokalen Rechner gespeichertes Frontend erhalten, während die gemeinsam genutzten Tabellen zentral auf dem Server liegen (s. Abb. 1).

Warum aufteilen?

Es gibt mehrere Gründe für diese Maßnahmen: Wenn mehrere Benutzer auf dieselben Dateien zugreifen, kommt es dort leicht zu Beschädigungen. Mit der beschriebenen Aufteilung sind diese Korruptionen wesentlich seltener. Sollte das Frontend doch einmal kaputt gehen, kann man es einfach und ohne Datenverlust austauschen. Durch lokal zugängliche Makros und Formulare gibt es weniger Netzwerkverkehr, weil nur die Daten über das Netz transportiert werden müssen. Ein weiterer Vorteil der Aufteilung ist, dass sich eine Frontend-Kopie jederzeit ändern lässt, ohne dass man die Anwendung deshalb gleich für alle User sperrt.

Konzepte zur Verteilung

Bei der klassischen Verteilung neuer Frontends im Netz laufen der Administrator und/oder der Entwickler durch den Betrieb zu jeder Arbeitsstation, schicken den Benutzer in die Kaffeepause und installieren das neue Frontend. Das kostet bei vielen Usern oder häufigen Updates Zeit und damit Geld.

Ebenso häufig anzutreffen ist das Kopieren der aktuellen Version des Frontends mit einer Batchdatei vom Server aus. Das erspart die Laufarbeit, verlangt aber, dass alle Benutzer die Anwendung beenden und kommt vielfach nur nachts in Betracht. Eine weitere Variante baut auf die Verteilung per E-Mail, setzt aber voraus, dass die Anwender neue Versionen selbst installieren können.

Frontend-Verteilung per Tool

Für eine wesentlich elegantere Verteilung sorgen die nachfolgend vorgestellten Tools. Das Prinzip ist einfach: Der Anwender startet dabei über seine Verknüpfung am Desktop nicht direkt die Anwendung, sondern ein Programm, das prüft, ob es am Server ein neueres Frontend gibt. Falls ja, kopiert die Anwendung diese neue Komponente vor dem Aufruf auf den Client.

Access, VB oder Batch?

Tools, die so arbeiten, kann man in zwei Gruppen einteilen: Solche, die auf Access basieren, und andere. Access-gestützte Tools bestehen aus einer .mdb- oder .mde-Datei und setzen im wesentlichen VBA-Dateibefehle wie Dir, Kill und FileCopy für den Update-Prozess ein.

Solche Hilfsmittel sind relativ leicht zu programmieren und durch jeden Access-Entwickler individuell anpassbar und erweiterbar.

Ein Nachteil ist die etwas schlechtere Performance der Startanwendung, weil eben .mdb- statt .exe-Dateien verwendet werden. Zudem sind sie von der Access-Version abhängig.

Es gibt viele Varianten solcher Tools, bei denen sich aber die Funktionalität auf die konkreten Bedürfnisse des Erstellers beschränkt.

Die Vor- und Nachteile von nicht mit Access erstellten Tools verhalten sich in etwa umgekehrt: Sie sind typischerweise mit VB erstellt oder kommen in Form einer Batchdatei.

Es handelt sich meistens um fertige, also nicht weiter anpassbare Tools mit umfangreicher Funktionalität. Sie sind jedoch zum Teil nicht sehr gut für Access einsetzbar.

MDB Loader and Updater

Der MDB Loader and Updater von Henry Habermacher ist unter www.dbdev.org im Download-Bereich verfügbar. Es handelt sich um eine Access-Anwendung (Version 97), die aber problemlos in neuere Versionen konvertiert werden kann. Das Tool setzt die Konfiguration aus Abb. 2 voraus.

Abb. 2: MDB Loader and Updater im Netz

Auf dem Server befindet sich das Backend, das neue Frontend und die eigentliche Anwendung namens MDBLoader.mdb. Auf dem Client-Rechner befindet sich das alte Frontend und ein Link zur Datei MDBLoader.mdb auf dem Server.

Vergleich per Versionsnummer

Um das Frontend zu aktualisieren, startet der Benutzer mit der passenden Verknüpfung die Datei MDBLoader.mdb. Diese vergleicht die Versionen der auf dem Client-Rechner und auf dem Server befindlichen Frontends.

Wenn die Version auf dem Server neuer ist, kopiert der MDBLoader das neue Frontend vom Server auf den Client und startet es. Die Prüfung der Versionen erfolgt dabei durch Tabelleneinträge in den Frontends oder wahlweise zusätzlich im Backend (s. Abb. 3).

Der Programmautor liefert zum leichteren Verständnis je ein Test-Frontend und -Backend mit. Die eigentliche Anwendung ist die MDBLoader.mdb, deren Oberfläche lediglich aus einem Formular besteht (s. Abb. 4).

Abb. 3: Die Versionstabelle in der Beispieldatenbank

Abb. 4: Hauptformular des MDB Loaders and Updaters

Dort trägt man die Positionen von Frontend, Frontend-Vorlage und Backend ein und gibt die Tabellen und Datenfelder an, in denen die zu vergleichenden Versionsnummern stehen.

In der Beispielkonfiguration aus Abb. 4 bezieht das Tool die Daten für den Versionsvergleich aus den beiden Frontends.

Um ein neues Frontend im angegebenen Verzeichnis zu veröffentlichen, muss man in der Tabelle Settings eine höhere Versionsnummer als die zuletzt benutzte vergeben, damit das Tool den Update-Prozess einleitet. Diesen startet man wie in Abb. 5 als ersten Test mit der Schaltfläche compare and update now.

Für den Praxiseinsatz liefert der Autor des Tools ebenfalls eine Vorlage mit, nämlich eine Verknüpfung zum Starten der MDBLoader.mdb. Diese übergibt mit der Befehlszeilenoption /cmd den Text "auto" an die Datenbank. Der Verknüpfungstext in der Beispielverknüpfung lautet:

"C:\Programme\Office97\Office\msaccess.exe"
"E:\Backend\MDBLoader.mdb" /cmd auto

Die Ereignisprozedur, die beim Öffnen des Startformulars Read Me First ausgeführt wird, wertet den Text mit der Command-Funktion aus. Falls er "auto" lautet, vergleicht die Routine die Angaben in den verknüpften Versionstabellen und tauscht gegebenenfalls das Frontend per FileCopy-Befehl gegen die neue Vorlage aus. Anschließend startet sie das Frontend.

Weitere Informationen zur verwendeten Technik finden Sie in den Objekten und dem Code der Datenbank. Da der Quellcode frei zugänglich ist, können erfahrene Entwickler das Tool leicht für spezielle Zwecke anpassen.

Zum einfachen Aktualisieren von Frontends brauchen Sie nur einmalig die beschriebenen Einstellungen im Setup-Formular des MDBLoaders richtig vorzunehmen und die Verknüpfungsdatei an die Anwender zu verteilen.

Abb. 5: Test der Versionen und des Update-Prozesses

Auto FE Updater

Das zweite Tool, Auto FE Updater, basiert nicht auf einer Access-Anwendung. Es stammt von Tony Toews und ist auf seiner Webseite www.granite.ab.ca/access/autofe.htm als Freeware erhältlich. Eventuellen Spenden wird sich der Autor aber nicht verschließen. Das Programm ist zwar mit Visual Basic erstellt, aber speziell für den Einsatz mit Access-Frontends ausgelegt. Daher bietet es viele in der Access-Praxis nützliche Einstellmöglichkeiten.

Abb. 6 zeigt eine ähnliche Struktur wie beim zuvor beschriebenen Tool.

Abb. 6: Auto FE Updater im Netz

Auf dem Server befinden sich das Backend, das neue Frontend und die Updater-Anwendung, in diesem Fall die StartMDB.exe. Zusätzlich liegt auf dem Server eine Konfiguationsdatei mit verschiedenen Informationen für den Update-Prozess.

Der Client-Rechner speichert eine Verknüpfung zur Updater-Anwendung, der Server das Frontend und eine weitere Konfigurationsdatei mit dessen Erstellungsdatum.

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

© 2003-2015 André Minhorst Alle Rechte vorbehalten.