Bibliotheksdatenbanken

In diesem sechsten und vorerst letzten Beitrag rund um das Thema Verweise geht es um Bibliotheksdatenbanken. Dieser Beitrag zeigt Ihnen, wann und warum Sie Ihren Code in eine Bibliothek auslagern sollten und worauf Sie achten müssen, damit es keine Probleme mit dem Verweis auf Ihre Bibliothek gibt.

Jeder Entwickler, der mehr als eine Access-Anwendung erstellt hat, baut mit der Zeit einen Fundus von Funktionen auf, die er immer wieder einsetzt. Doch wie verwaltet, verwendet und wartet man eine solche Funktionssammlung am besten

Warum Bibliotheksdatenbanken

Stellen Sie sich folgende Situation vor: Sie haben einige Funktionen rund um Datei- und Pfadangaben geschrieben und diese in einem Modul zusammengefasst. In jeder Anwendung, die Sie schreiben, benötigen Sie wohl irgendwann diese Dateifunktionen und importieren dazu jeweils das entsprechende Modul in die Datenbank.

Nun stellen Sie bei einer der in diesem Modul enthaltenen Funktionen einen Fehler fest und korrigieren ihn in der betreffenden Datenbank. Das eigentliche Problem ist, dass der Fehler auch in allen anderen Datenbanken mit diesem Modul enthalten ist und Sie dieses nun an allen Stellen ersetzen müssen, was schnell zu Inkonsistenzen führen kann.

Es hat sich als praktisch herausgestellt, solche immer wieder verwendeten Funktionen in einer einzigen Datenbank zu sammeln. Diese Bibliotheksdatenbank können Sie nun als Verweis in andere Anwendungen einbinden. Damit stehen alle Funktionen dieser Bibliothek auch in weiteren Anwendungen zur Verfügung (s. Abb. 1).

missing image file

Abb. 1: Häufig verwendete Funktionen werden in einer Bibliothek gebündelt und als Verweis eingebunden.

Dieses Vorgehen hat folgende Vorteile: Alle Standardfunktionen sind an einer Stelle verfügbar. Erweiterungen und Fehlerbereinigungen müssen daher nur einmal an einer Stelle durchgeführt werden. Dadurch, dass die Bibliothek nur in andere Anwendungen eingebunden ist, können Sie auch keine Anwendung bei der Aktualisierung vergessen.

Ein weiterer Vorteil liegt darin, dass es jede Ihrer Bibliotheks-Funktionen nur genau ein einziges Mal gibt. Es kommt nämlich nicht selten vor, dass sich ein und dieselbe Funktion in verschiedenen Anwendungen unterschiedlich entwickelt. Spätestens, wenn das Modul durch bloßes Kopieren aus einer anderen Anwendung aktualisiert wird, kann es zu Problemen kommen.

Die Verwendung einer Bibliotheksdatenbank birgt aber auch Gefahren. Dadurch, dass Sie alle Funktionen an einer Stelle konzentriert haben, wirkt sich eine änderung unter Umständen auf viele Anwendungen aus. Zu welchen Wechselwirkungen es dabei kommt, kann schwer vorhergesagt werden. Aus diesem Grund sollten Sie tief greifende änderungen einer Bibliotheks-Funktion sehr gut testen.

Vorsicht: Zirkelbezüge

Sie können Verweise auf andere Datenbanken setzen. Diese wiederum können Verweise auf weitere Datenbanken beinhalten (s. Abb. 2). Generell ist ein solches Vorgehen möglich.

missing image file

Abb. 2: Verweise auf andere Datenbanken sind möglich.

Sie sollten das aber vermeiden. Zum einen wird es schnell unübersichtlich, zum anderen besteht die Gefahr des Zirkelbezugs (s. Abb. 3).

missing image file

Abb. 3: Zirkelbezüge in den Verweisen kann Access nicht auflösen.

Von einem Zirkelbezug spricht man, wenn ein Verweis direkt oder indirekt auf die ursprüngliche Datenbank zurückverweist. Einen Zirkelbezug kann Access nicht auflösen. Sie werden in einem solchen Fall mit einer Fehlermeldung gewarnt.

.mdb oder .mde

Grundsätzlich können Sie Ihre Bibliotheksdatenbank als .mdb– oder als .mde-Datei speichern und einbinden. Bei der Wahl des Formats gibt es zwei Dinge zu beachten. Da wäre zum einen der Schutz Ihres Know-hows.

Wenn Sie alle Ihre Funktionen in einer Bibliothek sammeln und diese als .mdb-Datei an Dritte weiterreichen, dann geben Sie damit Ihre komplette Funktionssammlung ungeschützt aus der Hand.

Ihr Code ist für jeden einsehbar und kann durch jedermann angepasst und geändert werden.

Neben dem Schutz des Know-hows gibt es noch einen weiteren Punkt zu beachten, das Speicherformat der Zielanwendung. Wenn die Anwendung, in die Ihre Bibliotheksdatenbank als Verweis eingebunden werden soll, als .mdb-Datei vorliegt, können Sie dort eine .mdb-Datei und auch eine .mde-Datei als Verweis einbinden.

Wird Ihre Bibliothek hingegen in eine Anwendung eingebunden, die als .mde-Datei daher kommt, dann können Sie wiederum nur eine .mde-Datei einbinden. Ein Verweis auf eine .mdb-Datei führt in einem solchen Fall zu einem Fehler.

Vorsicht mit .mde-Bibliotheken

Aus dem bisher Gesagten könnte der Eindruck entstehen, dass Sie Ihre Bibliotheks-Datenbanken immer als .mde-Datei speichern sollten und damit alle Probleme beseitigt seien. Dies stimmt aber leider nicht ganz. Die Verwendung einer .mde-Datei als Bibliothek kann auch zu Fehlern führen.

Solche Fehler treten in folgender Konstellation auf. Sie verwenden eine Bibliotheksdatenbank, diese liegt als .mde-Datei vor und ist als Verweis in eine Anwendung eingebunden. Auch diese Anwendung liegt als .mde-Datei vor.

Jetzt ändern Sie den Code in der Bibliotheksdatenbank und speichern diese erneut als .mde-Datei.

Wenn Sie nun die Anwendung starten und dort eine Funktion aufrufen, deren Code in der Bibliotheksdatenbank gespeichert ist, quittiert Access dies mit einer Fehlermeldung (s. Abb. 4).

missing image file

Abb. 4: Eine geänderte .mde-Datei führt in der Anwendung zu einem Fehler.

Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...

Workplace

Jahresabonnement TestzugangOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

Schreibe einen Kommentar