Letzte Änderung am 29. Juni 2021 by Christoph Jüngling
Bei “normaler” Programmierung hat man eine Applikation. Punkt. Dazu gibt es meist im Hintergrund noch eine Möglichkeit, Daten zu speichern. Ob man diese nun Datenbank nennen möchte oder einfach nur Datei, ob selbiges nun lokal oder in der Cloud liegt, ist dabei erstmal egal, denn das ist nur eine technische Unterscheidung. Aber irgend so etwas zum Speichern braucht man wohl.
In diesem Artikel
Grundsätzliches
Eine Access-Datenbank wiederum kann viele Dinge beinhalten: Daten, Eingabeformulare, Druckvorlagen (Reports), sowie alle dazugehörigen Programmabläufe wie Makros oder VBA-Code. Auch wenn es auf den ersten Blick verlockend erscheint, alles unter einem Dach zu haben, wird dies spätestens bei mehreren Usern im Netzwerk schwierig zu handhaben — nicht unbedingt für die User, wohl aber für den oder die Entwickler.
Ein erfahrener Access-Entwickler trennt daher seine Applikation gern in Frontend und Backend auf, wenn sowohl die Applikation, als auch die Datenspeicherung von Access erledigt werden soll. So liegen gewisse Dinge an jeweils der Stelle, wo sie hingehören. Doch wo ist das?
Frontend
Das Frontend ist die Applikation. Hier steckt alles drin, was irgendwie aktiv sein soll:
- Abfragen
- Formulare
- Berichte
- Makros
- Module und Klassenmodule (das, was wir “VBA” nennen)
Der Zusatz “falls vorhanden” gilt natürlich für alle diese Objekte. Oft enthält eine Access-Applikation nur noch ein einziges Makro (“Autoexec”), oder sogar gar keins, weil es ein Start-Formular gibt, das alle notwendigen Aktionen im “Form_Open”-Event per Code erledigt. Aber das ist im Grunde nicht so wichtig.
Der Zugriff auf das Backend (genaugenommen auf die Tabellen des Backends) kann per eingebundenen Tabellen erfolgen. Denn das Frontend muss ja auch irgendwie an die Daten heran kommen. Theoretisch müsste dies nicht unbedingt über verknüpfte Tabellen gehen. Bei Server-Datenbanken sind auch Pass-Through-Abfragen möglich, oder der Code generiert Recordsets dynamisch und greift so direkt auf die ferne Datenbank zu. Wie wir wissen, gibt es bei Access viel “kann” und nur wenig “muss”. Man muss im Einzelfall entscheiden, was man braucht. Auch Performancegesichtspunkte sollten dabei berücksichtigt werden.
Backend
Im Backend liegen nur die Datentabellen und die Definitionen, wie diese miteinander verknüpft sind (“referenzielle Integrität”). Wer will, kann trotzdem noch ein Autoexec-Makro anlegen, das die Datenbank sofort wieder schließt, wenn ein Anwender sie im Netzwerk mal versehentlich geöffnet hat.
Das ist der klassische Weg, sehr hilfreich und nützlich. Doch warum? Und vor allem, was kommt nun wohin?
Wo ist das Baby Backend?
Das Access-Backend ist eine ganz normale Datenbank, früher .mdb, heute sicherlich vom Typ .accdb. Es enthält ausschließlich Tabellen und deren Verknüpfungen (siehe referentielle Integrität).
Natürlich habe ich auf meinem Entwicklungs-PC eine Backend-Datenbank liegen, schließlich muss ich die Datenbankapplikation ja auch testweise laufen lassen. Vielleicht liegt mein Backend sogar im selben Verzeichnis wie das Frontend, was absolut zulässig ist, aber keineswegs notwendig.
Beim Kunden werden vermutlich mehrere Anwender auf denselben Datenbestand zugreifen wollen. Aus diesem Grunde gehört das Backend in’s Netzwerk. Wo es genau liegt, muss niemand wissen außer dem Programm selbst und vielleicht dem Administrator. Man kann sich das in etwa so vorstellen:
Wie bereits in dem Artikel Wenn der Kunde mitarbeitet erklärt, verwende ich einen besonderen Mechanismus, um die Verbindung zwischen Frontend und Backend herzustellen.
Woher weiß das Frontend, wo das Backend liegt?
Wenn ich das Frontend so ausliefern würde, wie es bei mir entsteht, dann würde Access sich mit dem Backend verbinden wollen, das dort liegt, wo es bei mir liegt, also z.B. N:\MeinBackend\backend.accdb. Nur gibt es beim Anwender vielleicht gar kein N:-Laufwerk. Aus diesem Grunde lösche ich alle verknüpften Tabellen aus dem Frontend heraus, bevor ich es vom Setup-Programm verpacken lasse. Dann ist es auch etwas kleiner :-)
Um nun beim Anwender nicht sofort eine Fehlermeldung zu bekommen, setze ich AttachTables ein, eine Kombination aus Funktion und Klasse (Code siehe hier). Die Funktion liest aus einer INI-Datei den Pfad zum Backend aus und verknüpft damit alle Tabellen neu. Welche Tabellen das sind, erfährt die Klasse aus einer lokalen Tabelle, der einzigen, die in meinem Frontend existiert.
Die INI-Datei wird vom Setup nur beim ersten mal in das Installationsverzeichnis (bzw. das Einstellungsverzeichnis des Benutzers) geschrieben. Wenn sie vorhanden ist, wird sie vom Setup nicht mehr angefasst. So muss nur nach der Installation eine Anpassung vorgenommen werden. Wenn der Kunde jedoch bereits zuvor festgelegt hat, wo das Backend liegen soll, kann diese Information natürlich auch vom Setup initial in die INI-Datei eingetragen werden.
Bei jedem weitere Start wird die obige Funktion ebenfalls aufgerufen. Wenn sie jedoch feststellt, dass die verknüpften Tabellen bereits mit dem gewünschten Backend verbunden sind, macht sie einfach gar nichts. Das verlängert den Startprozess nur unwesentlich, denn es dauert nur einen Augenblick. So sind die Tabellen schnell (wieder) verknüpft. Es muss nur sichergestellt werden, dass vorher kein Zugriff darauf erfolgt, denn der würde unter Umständen einen Fehler auslösen. Aber ich denke, das kann man recht gut in den Griff bekommen.
Und wenn ich mehrere Backends brauche? Dann hilft dir vielleicht dieser Artikel weiter.
Neueste Kommentare