<\/p>\n
Lernen Sie zwei Tools zur Vereinfachung der Verteilung von Datenbank-Frontends in Mehrbenutzerumgebungen kennen.<\/p>\n
Frontend\/Backend<\/p>\n
Access 97 und höher<\/p>\n
Karl Donaubauer, Wien<\/b><\/p>\n
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.<\/b><\/p>\n
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.<\/p>\n
![](\"..\/fileadmin\/_temp_\/{2D73117E-BD25-4E5D-B68A-0E11AA7F936B}\/pic001.png\")
<\/p>\n
Bild 1: Backend und Frontends im Netz<\/span><\/b><\/p>\n 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 (siehe Bild 1).<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Solche Hilfsmittel sind relativ leicht zu programmieren und durch jeden Access-Entwickler individuell anpassbar und erweiterbar.<\/p>\n 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.<\/p>\n Es gibt viele Varianten solcher Tools, bei denen sich aber die Funktionalität auf die konkreten Bedürfnisse des Erstellers beschränkt.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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 Bild 2 voraus. <\/p>\n Bild 2: MDB Loader and Updater im Netz<\/span><\/b><\/p>\n 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.<\/p>\n 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.<\/p>\n 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 (siehe Bild 3).<\/p>\n 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 (siehe Bild 4). <\/p>\n <\/b><\/p>\n <\/p>\n Bild 3: Die Versionstabelle in der Beispieldatenbank<\/span><\/b><\/p>\n <\/b><\/p>\n Bild 4: Hauptformular des MDB Loaders and Updaters<\/span><\/b><\/p>\n 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.<\/p>\n In der Beispielkonfiguration aus Bild 4 bezieht das Tool die Daten für den Versionsvergleich aus den beiden Frontends.<\/p>\n 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 Bild 5 als ersten Test mit der Schaltfläche compare and update now.<\/p>\n 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:<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n <\/b><\/p>\n Bild 5: Test der Versionen und des Update-Prozesses<\/span><\/b><\/p>\n 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.<\/p>\n Bild 6 zeigt eine ähnliche Struktur wie beim zuvor beschriebenen Tool.<\/p>\n Bild 6: Auto FE Updater im Netz<\/span><\/b><\/p>\n 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.<\/p>\n Der Client-Rechner speichert eine Verknüpfung zur Updater-Anwendung, der Server das Frontend und eine weitere Konfigurationsdatei mit dessen Erstellungsdatum.<\/p>\n Die Updater-Anwendung vergleicht dieses Datum bei jedem Aufruf mit dem Erstellungsdatum des jüngsten Frontends auf dem Server und entscheidet danach über eine Aktualisierung.<\/p>\n In der Praxis hat es sich bewährt, drei Verzeichnisse auf dem Server einzurichten: Eins für das Backend, eins für das Frontend und eventuell weitere notwendige Dateien wie etwa DLLs (das Tool kopiert immer den kompletten Inhalt des Verzeichnisses) und eins für die StartMDB.exe und die passende Konfigurationsdatei. <\/p>\n Der Download liefert mehrere Muster für die Konfigurationsdatei auf dem Server, die den richtigen Einsatz der enthaltenen Parameter zeigen sollen. <\/p>\n Dabei ist nicht immer alles auf Anhieb verständlich. Wenn Sie das Tool zum ersten Mal benutzen, sollten Sie daher die einfach aufgebaute Konfigurationsdatei Getting Started.ini verwenden, sie für Ihre konkrete Situation anpassen und umbenennen (siehe Bild 7).<\/p>\n Bild 7: Eine einfache Beispiel-Konfigurationsdatei<\/span><\/b><\/p>\n Der Parameter MainApp legt den Zielort des Frontends auf dem Client-Rechner fest. Falls der angegebene Ordner auf dem Client-Rechner noch nicht existiert, legt ihn das Tool neu an. Der Parameter Server gibt an, wo das neue Frontend auf dem zentralen Rechner zu finden ist.<\/p>\n StartMethod entscheidet darüber, mit welcher Access-Version die Anwendung gestartet wird. Dabei gibt es drei Einstellmöglichkeiten: Bei AutoSelect ermittelt das Tool das Format der Frontend-Datenbankdatei und versucht, diese oder eine kompatible Access-Version am Arbeitsplatz zu starten.<\/p>\n In der Regel sollten Sie diese Variante verwenden. Für Ausnahmefälle gibt es ansonsten die Möglichkeit, den Pfad zur passenden msaccess.exe anzugeben oder die Version zu verwenden, die aktuell mit der Dateiendung .mdb verknüpft ist.<\/p>\n Die nächsten beiden Parameter Lockout und LockoutMsg dienen dazu, die Anwendung zu sperren und dem Benutzer eine entsprechende Meldung anzuzeigen, damit er überhaupt etwas von dem Vorgang mitbekommt.<\/p>\n Um mit der Datenbank zu arbeiten, klickt er wieder nur auf eine Verknüpfung und startet nicht direkt die eigentliche Anwendung, sondern das Programm StartMDB.exe auf dem Server. Dieses prüft die Einträge der Konfigurationsdatei. Stößt es dabei auf Lockout = Yes, zeigt es die LockoutMsg an und bricht den Startvorgang ab.<\/p>\n Das kann sehr hilfreich sein, wenn Sie vor änderungen am Backend verhindern müssen, dass Benutzer dieses durch einen Aufruf des Frontends blockieren. Anwender, die das Frontend bereits gestartet haben, müssen Sie auf herkömmliche Art per Telefon oder über andere Techniken dazu bewegen, sich vom Backend abzumelden.<\/p>\n Die letzten beiden Parameter der Konfigurationsdatei legen fest, ob eine Verknüpfung auf dem Desktop des Anwenders erzeugt werden und wie sie heißen soll.<\/p>\n Hier sind nur die wichtigsten Konfigurationsparameter vorgestellt. Daneben bietet der Auto FE Updater noch etliche andere, etwa zum Starten gesicherter Anwendungen oder zum Anlegen der Verknüpfung im Ordner Eigene Dateien des Clients.<\/p>\n Bild 8: Programmoberfläche des Auto FE Updaters<\/span><\/b><\/p>\n Bevor Sie die Anwendung StartMDB.exe auf dem Server starten (siehe Bild 8), sollten Sie die Verzeichnisse mit den zu aktualisierenden Dateien, der Anwendung StartMDB.exe und der Konfigurationsdatei (umbenannt etwa in Meine.ini) schon komplett angelegt haben.<\/p>\n Dann wählen Sie die Konfigurationsdatei Meine.Ini aus der Liste aus und prüfen mit einem Klick auf die Schaltfläche Validate INI File, ob alle Einstellungen gültig sind.<\/p>\n Falls nicht, liefert das Tool in der Regel aussagekräftige Fehlermeldungen.<\/p>\n Das einzige „Verteilungsproblem“ beim Auto FE Updater ist ebenso wie beim MDB Loader and Updater die Erstinstallation beziehungsweise der erste Aufruf der Updater-Anwendung.<\/p>\n Beim Auto FE Updater erledigt man das am besten über eine Verknüpfung. Die Schaltfläche Place launcher line on clipboard hilft dabei.<\/p>\n Man muss danach nur noch eine neue Verknüpfung anlegen und diese mit dem vom Tool in die Zwischenablage kopierten Text füllen, der etwa so aussieht:<\/p>\n Dieser Aufruf startet die Anwendung StartMDB.exe und übergibt als Parameter den Namen der zuvor erstellten Konfigurationsdatei.<\/p>\n Die Verknüpfung ruft man einmal von jeder Arbeitsstation aus auf, wobei es keine Rolle spielt, ob die Verknüpfung auf dem Client-Rechner oder auf dem Server liegt.<\/p>\n Dadurch legt die Anwendung das Frontend-Verzeichnis auf jedem Client-Rechner an und kopiert das aktuelle Frontend hinein.<\/p>\n Damit die Benutzer sich zukünftig selbst die aktuelle Version der Anwendung vom Server besorgen können, erzeugt das Tool zusätzlich eine passende Verknüpfung auf dem Desktop der Client-Rechner.<\/p>\n Diese erhält als Ziel ebenfalls die auf dem Server liegende Datei StartMDB.exe mit einem passenden Parameter, der den Namen der Konfigurationsdatei angibt.<\/p>\n Der Auto FE Updater bietet wesentlich mehr Möglichkeiten, als es dieses schlichte Beispiel zeigen konnte.<\/p>\n Es gibt zum Beispiel eine Konfigurationsdatei für den Einsatz mit dem Terminal Server, der in der Praxis immer häufiger als Mittel zur Beschleunigung von Access-Applikationen über langsame Leitungen anzutreffen ist – so sind „nur“ die Daten für die Anzeige zu übertragen, aber keine größeren Datenmengen, wie sie etwa beim Bereitstellen von Abfrage-Ergebnissen via Netzwerk vorkommen.<\/p>\n Beim Terminal Server gibt es nicht den üblichen Client mit eigener Festplatte. Trotzdem sollte jeder Anwender sein eigenes Frontend bekommen, schon um Korruptionen zu minimieren.<\/p>\n Zu diesem Zweck kann man als Ziel für die Frontend-Installation in der Konfigurationsdatei etwa folgenden Ausdruck angeben:<\/p>\n Die Variable %user% enthält den Anmeldenamen des Anwenders am Terminal Server. Der Eintrag sorgt daher dafür, dass am Terminal Server Z für jeden Anwender ein Verzeichnis mit seinem Anmeldenamen zum Speichern des jeweiligen Frontends eingerichtet wird. Auch diese Variante bewährt sich seit Jahren im Praxiseinsatz.<\/p>\n Weitere Informationen zu allen Möglichkeiten des Auto FE Updaters finden Sie auf der Webseite von Tony Toews.<\/p>\n Die Ausführungen sind zwar nicht immer leicht zu verstehen, aber die Funktionen des Tools rechtfertigen die nötige Einarbeitungszeit.<\/p>\n Viele Entwickler haben für ihre eigenen Anwendungen ähnliche Access-basierte Tools wie das von Henry Habermacher programmiert.<\/p>\n Es gibt auch kostenpflichtige Alternativen, die speziell für den Einsatz mit Access ausgelegt sind. Ein Beispiel ist das knapp 500,- Dollar teure Total Access Startup des in der Access-Welt recht bekannten Toolherstellers FMS (www.fmsinc.com).<\/p>\n Es ist hübsch anzusehen, kann aber bezüglich des Funktionsumfangs dem kostenlosen Auto FE Updater von Tony Toews nicht das Wasser reichen.<\/p>\n Wenn man sich mit den nicht immer professionellen Dokumentationen zu den hier vorgestellten Tools arrangieren kann, spart man gegenüber kostenpflichtigen Tools zumindest eine Menge Geld; und im Falle des Auto FE Updaters bekommt man sogar noch mehr Funktionen.<\/p>\n","protected":false},"excerpt":{"rendered":" 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662006,66042006,44000020],"tags":[],"class_list":["post-55000370","post","type-post","status-publish","format-standard","hentry","category-662006","category-66042006","category-Tools"],"yoast_head":"\nWarum aufteilen<\/h3>\n
Frontend-Verteilung per Tool<\/h3>\n
Access, VB oder Batch<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{2D73117E-BD25-4E5D-B68A-0E11AA7F936B}\/pic002.png\")
<\/p>\nVergleich per Versionsnummer<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{2D73117E-BD25-4E5D-B68A-0E11AA7F936B}\/pic003.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{2D73117E-BD25-4E5D-B68A-0E11AA7F936B}\/pic004.png\")
<\/p>\n\"C:\\Programme\\Office97\\Office\\msaccess.exe\"\"E:\\Backend\\MDBLoader.mdb\" \/cmd auto<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{2D73117E-BD25-4E5D-B68A-0E11AA7F936B}\/pic005.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{2D73117E-BD25-4E5D-B68A-0E11AA7F936B}\/pic006.png\")
<\/p>\nVergleich per Erstellungsdatum<\/h3>\n
Konfiguration<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{2D73117E-BD25-4E5D-B68A-0E11AA7F936B}\/pic007.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{2D73117E-BD25-4E5D-B68A-0E11AA7F936B}\/pic008.png\")
<\/p>\nErstinstallation per Verknüpfung<\/h3>\n
E:\\FEUpdater\\StartMDB.exe \/cmd \/inifile:\"E:\\FEUpdater\\Meine.ini\"<\/pre>\n
Einsatz mit dem Terminal Server<\/h3>\n
MainApp=Z:\\%user%\\Frontend.mdb<\/pre>\n