<\/p>\n
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.<\/b><\/p>\n
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<\/p>\n
Warum Bibliotheksdatenbanken<\/b><\/p>\n
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.<\/p>\n
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.<\/p>\n
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 (siehe Bild 1).<\/p>\n
![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Verweise-web-images\/Bild23298_opt.jpeg\")
<\/p>\n
Bild 1: Häufig verwendete Funktionen werden in einer Bibliothek gebündelt und als Verweis eingebunden.<\/span><\/b><\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Vorsicht: Zirkelbezüge<\/b><\/p>\n Sie können Verweise auf andere Datenbanken setzen. Diese wiederum können Verweise auf weitere Datenbanken beinhalten (siehe Bild 2). Generell ist ein solches Vorgehen möglich.<\/p>\n Bild 2: Verweise auf andere Datenbanken sind möglich.<\/span><\/b><\/p>\n Sie sollten das aber vermeiden. Zum einen wird es schnell unübersichtlich, zum anderen besteht die Gefahr des Zirkelbezugs (siehe Bild 3).<\/p>\n Bild 3: Zirkelbezüge in den Verweisen kann Access nicht auflösen.<\/span><\/b><\/p>\n 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.<\/p>\n .mdb oder .mde<\/b><\/p>\n Grundsätzlich können Sie Ihre Bibliotheksdatenbank als .mdb<\/b>– oder als .mde<\/b>-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.<\/p>\n Wenn Sie alle Ihre Funktionen in einer Bibliothek sammeln und diese als .mdb<\/b>-Datei an Dritte weiterreichen, dann geben Sie damit Ihre komplette Funktionssammlung ungeschützt aus der Hand.<\/p>\n Ihr Code ist für jeden einsehbar und kann durch jedermann angepasst und geändert werden.<\/p>\n 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<\/b>-Datei vorliegt, können Sie dort eine .mdb<\/b>-Datei und auch eine .mde<\/b>-Datei als Verweis einbinden.<\/p>\n Wird Ihre Bibliothek hingegen in eine Anwendung eingebunden, die als .mde<\/b>-Datei daher kommt, dann können Sie wiederum nur eine .mde<\/b>-Datei einbinden. Ein Verweis auf eine .mdb<\/b>-Datei führt in einem solchen Fall zu einem Fehler.<\/p>\n Vorsicht mit .mde-Bibliotheken<\/b><\/p>\n Aus dem bisher Gesagten könnte der Eindruck entstehen, dass Sie Ihre Bibliotheks-Datenbanken immer als .mde<\/b>-Datei speichern sollten und damit alle Probleme beseitigt seien. Dies stimmt aber leider nicht ganz. Die Verwendung einer .mde<\/b>-Datei als Bibliothek kann auch zu Fehlern führen.<\/p>\n Solche Fehler treten in folgender Konstellation auf. Sie verwenden eine Bibliotheksdatenbank, diese liegt als .mde<\/b>-Datei vor und ist als Verweis in eine Anwendung eingebunden. Auch diese Anwendung liegt als .mde<\/b>-Datei vor.<\/p>\n Jetzt ändern Sie den Code in der Bibliotheksdatenbank und speichern diese erneut als .mde<\/b>-Datei.<\/p>\n Wenn Sie nun die Anwendung starten und dort eine Funktion aufrufen, deren Code in der Bibliotheksdatenbank gespeichert ist, quittiert Access dies mit einer Fehlermeldung (siehe Bild 4).<\/p>\n Bild 4: Eine geänderte .mde-Datei führt in der Anwendung zu einem Fehler.<\/span><\/b><\/p>\n <\/p>\n Die Lösung dieses Problems ist relativ einfach: Nachdem Sie die Bibliotheksdatenbank erneut als .mde<\/b>-Datei gespeichert haben, müssen Sie auch die Anwendung erneut in eine .mde<\/b>-Datei umwandeln – beide müssen neu kompiliert werden.<\/p>\n Das Kind braucht einen Namen<\/b><\/p>\n Im Verweise-Dialog sind alle Bibliotheken über einen Namen eindeutig zu identifizieren. Die Frage ist, welchen Namen Ihre Bibliotheksdatenbank erhält und wie Sie diesen Namen beeinflussen können.<\/p>\n Als Name für den Verweis wird bei einer Bibliotheksdatenbank der Name des VBA-Projekts verwendet. Diesen Namen können Sie anpassen. Öffnen Sie dazu die Bibliotheksdatenbank. Im VBA-Editor wählen Sie aus dem Menü den Befehl Extras <\/b>und dort den Eintrag Eigenschaften von <Projektname><\/b> (siehe Bild 5). Hier passen Sie jetzt den Projektnamen an. Zusätzlich können Sie eine Projektbeschreibung eingeben. Diese Projektbeschreibung kann über die Eigenschaft Description <\/b>eines Reference<\/b>-Objektes wieder ausgelesen werden.<\/p>\n Bild 5: Über den Namen des VBA-Projekts bestimmen Sie den Namen des Verweises.<\/span><\/b><\/p>\n An dieser Stelle verhalten sich Verweise, die Sie über eine Type-Library eingebunden haben, anders als Verweise auf ein VBA-Projekt. Bei einer Type-Library ist die Eigenschaft Description <\/b>verantwortlich für den angezeigten Namen des Verweises im Verweise-Dialog. Dieser kann deutlich vom eigentlichen Namen des Verweises abweichen.<\/p>\n Bei einem Verweis auf ein VBA-Projekt entsprechen sowohl der angezeigte Name im Verweise<\/b>-Dialog als auch der Name des Verweises dem Namen des VBA-Projekts.<\/p>\n Manchmal kommt es vor, dass Sie beim Versuch, einen Verweis auf eine Bibliotheksdatenbank einzufügen, mit einer Fehlermeldung konfrontiert werden. Access meldet dann Name steht in Konflikt mit vorhandenem Modul, Projekt oder vorhandener Objektbibliothek<\/b>. In diesem Fall existiert entweder bereits ein Verweis mit dem Namen der einzufügenden Bibliothek oder ihr Name ist identisch mit dem Namen des aktuellen VBA-Projekts.<\/p>\n Um solche Situationen zu vermeiden, sollten Sie immer darauf achten, dass Sie das VBA-Projekt eindeutig benennen. Access legt ja selbstständig einen Namen für das VBA-Projekt fest, und dabei wird zunächst der Dateiname der Datenbank verwendet. Wenn man bedenkt, dass viele Datenbanken am Anfang etwa db1.mdb <\/b>heißen und dann später umbenannt werden, wird schnell klar, woher solche Namenskonflikte stammen.<\/p>\n Praktische Hinweise<\/b><\/p>\n Der VBA-Editor unterstützt Sie bei der Arbeit mit eingebundenen Bibliotheksdatenbanken. Sie können jederzeit in den VBA-Code der Bibliotheksdatenbank wechseln, ohne dazu die Anwendung verlassen zu müssen.<\/p>\n Probieren Sie es einfach aus. Öffnen Sie dazu die Beispieldatenbank mit dem Namen MyApp.mdb<\/b>. Lassen Sie sich dort den VBA-Code zur Schaltfläche cmdMyButton<\/b> anzeigen. Platzieren Sie den Cursor in den Aufruf der Funktion MyFunction<\/b>. Öffnen Sie als Nächstes das Kontextmenü mit der rechten Maustaste und wählen Sie den Befehl Definition<\/b>.<\/p>\n Im VBA-Editor wird nun das Modul mit dem Namen mdl_MyModul <\/b>angezeigt. Dieses Modul stammt aus der Bibliotheksdatenbank. Der Cursor befindet sich am Beginn der Prozedur MyFunction<\/b>.<\/p>\n Dass Sie sich wirklich im Code der Bibliotheksdatenbank befinden, können Sie auch am Fenstertitel des VBA-Editors sehen. Dort werden Ihnen jeweils der Name des bearbeiteten Moduls und der Name der Datenbank, in dem dieses Modul gespeichert ist, angezeigt.<\/p>\n Sie können auch über den Projekt-Explorer auf die Module der Bibliotheksdatenbank zugreifen (siehe Bild 6). Zum Öffnen des Projekt-Explorers wählen Sie aus dem Menü Ansicht<\/b> den gleichnamigen Befehl. Alternativ können Sie auch die Tastenkombination Strg + R <\/b>verwenden.<\/p>\n Bild 6: Der Projekt-Explorer ermöglicht den Zugriff auf die Module einer Bibliotheksdatenbank.<\/span><\/b><\/p>\n Der Zugriff auf den Code der Bibliotheksdatenbank ist ideal für das Debugging. Sie können einen Haltepunkt im VBA-Code setzen und dann Zeile für Zeile durch den Code navigieren. Dabei wird auch in den Code der Bibliotheksdatenbank gewechselt.<\/p>\n Diese Möglichkeit, den VBA-Code der Bibliotheksdatenbank zu bearbeiten, hat leider einen entscheidenden Nachteil. änderungen, die Sie am Code der Bibliotheksdatenbank vornehmen, werden nur während der Ausführung der Anwendung berücksichtigt. Diese änderungen werden aber unter Access nicht dauerhaft in der Bibliotheksdatenbank gespeichert.<\/p>\n Die Möglichkeit, auf den VBA-Code zuzugreifen und diesen zu bearbeiten, ist also nur zum Zweck des Debuggings geeignet. Wenn Sie auf diesem Weg einen Fehler gefunden haben, können Sie die notwendige änderung des VBA-Codes nur ausprobieren. Am Ende müssen Sie die Bibliotheksdatenbank direkt öffnen und die Korrektur des VBA-Codes dort vornehmen.<\/p>\n Verweisprobleme vermeiden<\/p>\n Nachdem Sie jetzt etwa alle regelmäßig genutzten Funktionen in eine Bibliotheksdatenbank ausgelagert und diese als Verweis in Ihre Anwendung eingebunden haben, gilt es zu überlegen, wie Sie Dateiprobleme mit dem Verweis auf die Bibliotheksdatenbank vermeiden können.<\/p>\n Solange Sie die Anwendung nur auf Ihrem eigenen Rechner betreiben, stellt sich das Problem weniger. Wenn Sie aber Ihre Anwendung, und damit auch Ihre Bibliotheksdatenbank, an Dritte weitergeben, beginnt das Problem mit den Verweisen erneut.<\/p>\n Sie werden wahrscheinlich selten die Situation antreffen, dass dort genau dieselbe Verzeichnisstruktur vorhanden ist, wie auf Ihrem Rechner. Wie können Sie dann vermeiden, dass Ihre Anwendung nicht richtig funktioniert, weil der Verweis auf die Bibliotheksdatenbank nicht aufgelöst werden kann<\/p>\n Eintrag in der Registry<\/b><\/p>\n Um dieses Problem zu lösen, haben Sie grundsätzlich zwei Möglichkeiten. Die erste Möglichkeit liegt in der Nutzung der Registry. Fügen Sie in den Ordner HKLM\\Software\\Microsoft\\Office\\x.0\\Access <\/b>einen Ordner mit dem Namen RefLibPaths <\/b>ein. In diesem Ordner legen Sie einen Schlüssel mit dem Namen Ihrer Bibliotheksdatenbank an. Als Wert tragen Sie den Pfad zur Bibliotheksdatenbank ein. Ein Schritt-für-Schritt-Beispiel für diese Lösung finden Sie unter [2].<\/p>\n Wie funktioniert die Lösung Auf der Suche nach einem Verweis prüft Access zuerst den Eintrag RefLibPaths <\/b>in der Registry und lädt die Bibliotheksdatenbank gegebenenfalls von dem hier genannten Ort.<\/p>\n Im richtigen Ordner speichern<\/b><\/p>\n Die zweite Möglichkeit, um Verweisprobleme mit Bibliotheksdatenbanken zu vermeiden, ist, Ihre Bibliotheksdatenbank in den Ordner zu kopieren, in dem sich auch Ihre Anwendung befindet. Alternativ können Sie auch einen Unterordner des Anwendungsverzeichnisses verwenden. Warum diese Lösung funktioniert, können Sie unter [1] nachlesen. Wir haben dieses Thema auch im Beitrag Defekte Verweise: Ursachen und Lösungen <\/b>(Shortlink 572) ausführlich behandelt. Access durchforstet auf der Suche nach einem nicht gefundenen Verweis als letzte Möglichkeit das Verzeichnis, in dem sich die Access-Anwendung befindet, sowie alle zugehörigen Unterordner.<\/p>\n Sie können sich auf einfache Art vergewissern, dass diese Lösung funktioniert. Legen Sie dazu im Windows-Explorer einen beliebigen Ordner an. In diesen Ordner kopieren Sie die beiden Beispieldatenbanken MyApp.mdb <\/b>und MyLib.mdb<\/b>. Die Datenbank MyLib.mdb <\/b>ist als Verweis in die Datenbank MyApp.mdb <\/b>eingebunden.<\/p>\n Starten Sie jetzt MyApp.mdb <\/b>und klicken Sie auf die Schaltfläche im angezeigten Formular. Wenn alles richtig funktioniert, erscheint ein Meldungsfenster. Nun verschieben Sie den Ordner an eine beliebige Stelle im Verzeichnisbaum. Starten Sie wieder MyApp.mdb <\/b>und klicken Sie erneut auf die Schaltfläche. Sie werden wieder ein Meldungsfenster sehen. Wechseln Sie jetzt in den VBA-Editor und öffnen Sie dort den Verweise-Dialog. Sie werden feststellen, dass Access den Pfad zum Verweis eigenständig an den neuen Ordner angepasst hat. Funktioniert dieses Vorgehen auch in einer .mde<\/b>-Datei <\/p>\n Dass dieses Vorgehen auch in einer .mde<\/b>-Datei funktioniert, können Sie leicht selbst ausprobieren. Erstellen Sie dazu aus der Datenbank MyLib.mdb <\/b>eine .mde<\/b>-Datei. Binden Sie diese als Verweis in MyApp.mdb <\/b>ein und wandeln Sie diese ebenfalls in eine .mde<\/b>-Datei um. Verschieben Sie jetzt den Ordner mit der Anwendung und der Bibliothek an eine beliebige Stelle im Verzeichnisbaum und starten Sie die Anwendung. Wenn Sie auf die Schaltfläche klicken, erscheint das erwartete Meldungsfenster.<\/p>\n Alternative Strategien<\/b><\/p>\n Eine alternative Strategie für den Umgang mit häufig genutzten Prozeduren wäre, diese an einer einzigen Stelle zu verwalten und dann bei Bedarf in die jeweilige Anwendung zu kopieren. So hätten Sie den Vorteil, dass Sie Ihre Prozeduren nur an einer Stelle zu bearbeiten brauchen. Das Risiko, dass Ihre Bibliotheksdatenbank nicht gefunden wird, entfällt, da Sie keine Bibliothek als Verweis verwenden.<\/p>\n Sie könnten eine solche Strategie durch den Einsatz eines Quellcodeverwaltungsprogramms wie etwa Visual Source Safe umsetzen. Dort besteht die Möglichkeit, Objekte gemeinsam zu nutzen.<\/p>\n Dabei werden änderungen an einem Objekt automatisch in allen anderen Anwendungen nachgeführt. Eine weitere Lösung wäre, dass Sie sich selbst ein kleines Programm schreiben, das die jeweils aktuelle Version eines Moduls in Ihre Anwendung kopiert, bevor Sie diese ausliefern.<\/p>\n Zusammenfassung<\/b><\/p>\n Durch den Einsatz einer Bibliotheksdatenbank steht Ihnen eine Möglichkeit zur Verfügung, häufig verwendete Prozeduren und Module effizient zu verwalten. Diese Bibliotheksdatenbank als .mde<\/b>-Datei zu speichern, schützt Ihr Know-how. Wenn Ihre Anwendung ebenfalls als .mde<\/b>-Datei vorliegt, müssen Sie auch diese neu erstellen, wenn Sie die Bibliotheksdatenbank ändern.<\/p>\n Sorgen Sie dafür, dass das VBA-Projekt Ihrer Bibliothek einen entsprechenden Namen bekommt. Dieser wird als Name des Verweises übernommen. Denken Sie auch daran, dass Sie den VBA-Code der Bibliothek aus Ihrer Anwendung heraus zwar ändern können, dass diese änderungen aber nicht dauerhaft sind. Probleme mit den Verweisen umgehen Sie am besten, indem Sie die Bibliotheksdatenbank im selben Ordner wie Ihre Anwendung speichern.<\/p>\n Quellen<\/p>\n [1] KB 824255: So löst Access Verweise auf. http:\/\/support.microsoft.com\/kb\/824255\/de<\/a><\/p>\n [2] RefLibPaths Schritt für Schritt: http:\/\/smsconsulting.spb.ru\/shamil_s\/topics\/testrefs.htm<\/a><\/p>\n Enthaltene Beispieldateien:<\/p>\n MyApp.mdb<\/p>\n MyLib.mdb<\/p>\n![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Verweise-web-images\/Bild23305_opt.jpeg\")
<\/p>\n![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Verweise-web-images\/Bild23312_opt.jpeg\")
<\/p>\n![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Verweise-web-images\/Bild23334_opt.jpeg\")
<\/p>\n![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Verweise-web-images\/Bild23341_opt.jpeg\")
<\/p>\n![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Verweise-web-images\/Bild23348_opt.jpeg\")
<\/p>\nDownloads zu diesem Beitrag<\/h3>\n