<\/p>\n
In diesem dritten Teil der Beitrags-Reihe rund um das Thema „Verweise“ steigen wir tiefer in die Materie ein: Wie löst Access beziehungsweise VBA Verweise überhaupt auf Was läuft bei defekten Verweisen schief Und welche manuellen und welche VBA-Techniken gibt es, um solche Probleme zu lösen All dies erfahren Sie im vorliegenden Beitrag.<\/b><\/p>\n
Um die von Verweisen ausgehenden Probleme zu verstehen, sollten Sie wissen, wie Access, genauer VBA, vorgeht, um die Bibliothek eines Befehls zu finden. <\/p>\n
Disambiguation<\/b><\/p>\n
VBA verwendet Disambiguation, um die passende Bibliothek für ein Objekt oder eine Methode zu finden. Wenn VBA (unbekannte) Objekte im Code findet, erfolgt die Suche in der folgenden Reihenfolge:<\/p>\n
Woher weiß VBA beispielsweise, was sich hinter dem Befehl Left$ <\/b>verbirgt VBA prüft als Erstes, ob es in dem Modul, in dem es diese Codezeile findet, eine private oder öffentliche Funktion mit dem Namen Left$ <\/b>gibt. Wenn eine Funktion mit dem Namen Left$ <\/b>in diesem Modul vorhanden ist, verwendet es diese Funktion. Wenn das Modul kein passende Funktion enthält, prüft Access, ob in den anderen Standardmodulen der Datenbank eine öffentliche Funktion mit dem Namen Left$ <\/b>vorhanden ist.<\/p>\n
Offenbart das gesamte VBA-Projekt keine Funktion mit dem Namen Left$<\/b>, durchsucht Access als Nächstes alle nicht eingebauten Verweise der Datenbank (also alle außer Access und VBA) in der Reihenfolge ihrer Priorität. Findet Access auch in diesen Verweisen nichts, untersucht es die eingebauten Verweise VBA <\/b>und Access <\/b>nach diesem Befehl. Im Fall von Left$ <\/b>führt dies im Modul Strings <\/b>der Bibliothek VBA <\/b>zum Erfolg.<\/p>\n
Sie können diesen Prozess mit der Beispieldatenbank Demo.Disambiguation.mdb<\/b> nachvollziehen. Sorgen Sie vor dem Start dafür, dass die Bibliotheksdatenbank mit dem Namen Lib.Disambiguation.mdb<\/b> im selben Verzeichnis wie die Beispieldatenbank liegt. <\/p>\n
In der Beispieldatenbank können Sie über eine Schaltfläche zum VBA-Code wechseln. Setzen Sie dort den Cursor in den Befehl Left$<\/b>. Wählen Sie den Eintrag Definition <\/b>aus dem Kontextmenü aus und schauen Sie, wo sich der Befehl befindet.<\/p>\n
Kommentieren Sie nun die gefundene Funktion aus und wählen Sie erneut Definition. Wiederholen Sie diese Schritte so lange, bis der Objektkatalog am Ende den Befehl Left$ <\/b>anzeigt.<\/p>\n
Disambiguation vermeiden<\/p>\n
Sie können vermeiden, dass VBA auf der Suche nach der passenden Bibliothek den Prozess der Disambiguation durchläuft. Stellen Sie dazu dem Befehlswort den Namen der zu verwendenden Bibliothek und\/oder des zu verwendenden Moduls voran. Im Fall von Left$ <\/b>würden Sie dann Folgendes schreiben:<\/p>\n Wenn Sie einen Befehl aus der Access-Bibliothek verwenden wollen, schreiben Sie beispielsweise:<\/p>\n Für den Aufruf einer Funktion mit dem Namen MyFunction <\/b>aus dem Modul basMyModul <\/b>schreiben Sie:<\/p>\n Wenn sich das Modul in einer als Verweis eingebundenen Bibliothek befindet, stellen Sie den Namen der Bibliothek zusätzlich voran. Bezogen auf das vorherige Beispiel haben Sie nun folgende Möglichkeiten:<\/p>\n Sie können VBA die Arbeit abnehmen und die Befehle vollständig qualifiziert ausschreiben, Sie müssen es aber nicht. Wenn Sie es tun, nehmen Sie VBA nicht nur die Suche nach der richtigen Bibliothek ab. Sie legen auch definitiv fest, welche Bibliothek verwendet wird. Das ist insbesondere dann von Bedeutung, wenn ein Objekt oder eine Methode in mehreren Bibliotheken zugleich vorhanden ist.<\/p>\n Ein Beispiel hierfür ist das Recordset<\/b>-Objekt. Das Recordset<\/b>-Objekt ist in den Bibliotheken ADODB <\/b>und DAO <\/b>zu finden. Wenn Sie bei der Deklaration des Recordset-Objekts keine spezielle Bibliothek angeben und nur eine der beiden Bibliotheken per Verweis eingebunden ist, verwendet Access diese, sonst die mit der höheren Priorität.<\/p>\n Geben Sie hingegen bei der Deklaration des Recordset-Objekts bereits die zu verwendende Bibliothek an, verwendet VBA die „richtige“ Bibliothek. Wenn der zugehörige Verweis fehlt, erhalten Sie bereits beim Kompilieren eine Fehlermeldung.<\/p>\n Prüfen der Verweise<\/b><\/p>\n Wenn VBA prüfen will, ob ein Objekt in der Type Library eines Verweises enthalten ist, ermittelt es den intern gespeicherten GUID zu diesem Verweis. Mit dieser Information fragt VBA die Registry ab. Als Ergebnis erhält VBA letztlich den Pfad zur Datei mit der Type Library zurück.<\/p>\n Wenn sich diese Datei am erwarteten Ort befindet, lädt VBA sie in den Speicher und prüft, ob diese Type Library Informationen zu dem gesuchten Objekt enthält. Enthält die Type Library das Objekt nicht, sucht VBA in den anderen Verweisen in der Reihenfolge ihrer Priorität weiter. Als Letztes kommen dabei die eingebauten Verweise Access und VBA zum Zuge. <\/p>\n Wenn VBA den gesuchten Befehl nicht finden konnte, quittiert VBA dies beim Kompilieren mit der Fehlermeldung Sub oder Function nicht definiert<\/b>.<\/p>\n Den gesamten Prozess können Sie Bild 1 und Abb. 2 nachvollziehen. Aus diesen Schaubildern lassen sich folgende Erkenntnisse ableiten: Aus der Tatsache, dass Access Befehle zuerst im VBA-Projekt der Anwendung sucht, wird deutlich, dass Sie die Befehle, die VBA bereitstellt, durch eine eigene Version ersetzen können. Welche Möglichkeiten sich daraus ergeben und worauf Sie dabei achten sollten, wird in einem gesonderten Beitrag beschrieben. <\/p>\n Bild 1: Vom Befehl im VBA-Code …<\/span><\/b><\/p>\n Bild 2: … zur passenden Bibliothek<\/span><\/b><\/p>\n Wenn VBA beim Versuch, eine Type Library zu laden, auf ein Problem stößt, bricht der Prozess der Disambiguation ab. VBA lässt dann nicht etwa die fehlerhafte Bibliothek aus und sucht in den anderen Bibliotheken weiter, sondern bricht den Prozess komplett ab.<\/p>\n Wenn Sie sich nochmals in Erinnerung rufen, dass VBA die eingebauten Verweise erst am Ende durchsucht, wird deutlich, warum VBA so oft behauptet, der Befehl Left$ <\/b>könne nicht gefunden werden. Dies liegt wohl ganz einfach daran, dass VBA auf der Suche nach der richtigen Bibliothek auf einen anderen, fehlerhaften Verweis gestoßen ist.<\/p>\n Fehlerhafte Verweise<\/b><\/p>\n Nachdem jetzt klar ist, was bei einem defekten Verweis passiert, ist es an der Zeit zu überlegen, wie es zu defekten Verweisen kommen kann.<\/p>\n Ein Verweis ist fehlerhaft, wenn auf dem ausführenden Rechner nicht dieselbe Version einer Bibliothek registriert ist, sie gar nicht registriert ist oder wenn die registrierte Datei nicht gefunden werden kann. Die Gründe dafür sind vielfältig. So kann es zum Beispiel sein, dass auf dem ausführenden Rechner eine ältere oder eine neuere Version einer Bibliothek registriert ist.<\/p>\n Es kann aber auch passieren, dass ein Verweis komplett fehlt. Dies kann dann der Fall sein, wenn die Type Library auf diesem Rechner (noch) nicht registriert worden ist oder wenn die Registrierung aufgehoben wurde, weil beispielsweise eine Komponente vom System entfernt wurde. Zu einem fehlerhaften Verweis kommt es auch, wenn die registrierte Datei umbenannt, verschoben oder gelöscht wurde.<\/p>\n Auch das Durchbrechen der so genannten binären Kompatibilität führt zu einem fehlerhaften Verweis. Dafür, dass dies nicht passiert, ist der Programmierer der Komponente verantwortlich. Leider passieren hier hin und wieder Fehler, auf die Sie keinen Einfluss haben.<\/p>\n Wo erfolgt Disambiguation<\/b><\/p>\n Als Nächstes ist zu überlegen, wann und wo VBA es überall mit Verweisen zu tun haben kann. Daraus ergibt sich dann, wann und wo sich ein Fehler in den Verweisen auswirken kann. Der Prozess der Disambiguation erfolgt zum einen in VBA, zum anderen wird dieser Prozess aber auch vom (Jet) Expression Service genutzt. Der Expression Service ist dafür verantwortlich, dass Ausdrücke ausgewertet werden. Solche Ausdrücke können an folgenden Stellen verwendet werden:<\/p>\n Auch in diesen Ausdrücken können Sie VBA-Befehle verwenden. Der Expression-Service sorgt dann dafür, dass das richtige Ergebnis ermittelt wird, und gibt dieses zurück an die Abfrage oder an das Steuerelement.<\/p>\n Unterschiede in MDB und MDE ()<\/b><\/p>\n Lassen Sie uns kurz die Frage betrachten, ob es Unterschiede zwischen einer .mdb<\/b>-Datei und einer .mde<\/b>-Datei gibt, wenn es um Verweise geht. In einer nicht kompilierten .mdb<\/b>-Datei wird der Code modulweise geladen. Das gesamte Modul wird interpretiert. Dabei werden die passenden Klassen gesucht. Wenn dabei ein fehlerhafter Verweis gefunden wird, kommt es zur Fehlermeldung.<\/p>\n In einer kompilierten .mdb<\/b>-Datei und in einer .mde<\/b>-Datei ist der Ablauf etwas anders. Dort ist der Code bereits kompiliert. Es erfolgt also keine Suche mehr nach der passenden Klasse. Dies ist bereits bei der Kompilierung erfolgt. Wenn jetzt aber ein fehlerhafter Verweis geladen werden soll, gibt es auch in diesem Fall eine Fehlermeldung. Im Ergebnis unterscheiden sich .mdb<\/b>-Datei und .mde<\/b>-Datei also nicht. Wenn fehlerhafte Verweise vorhanden sind, führt dies zu einem Fehler.<\/p>\n <\/p>\n Wie löst Access Verweise auf<\/b><\/p>\n Als Nächstes sollten Sie sich anschauen, wie Access Verweise auflöst. Dies ist verkürzt etwa bei Microsoft in [1] dokumentiert. Wenn Sie wissen, wie und wo VBA nach Verweisen sucht, können Sie diese Möglichkeiten auch für Ihre Bibliotheksdatenbanken nutzen. Access geht in folgenden drei Schritten vor:<\/p>\n Als Erstes wird geprüft, ob der benötigte Verweis bereits geladen ist. Dies ist für Access die beste Situation, weil dann keine Fehler mehr auftreten können. Als Zweites wird geprüft, ob in der Registry ein Schlüssel mit dem Namen RefLibPaths <\/b>existiert. Dieser Schlüssel wird in folgendem Pfad gesucht:<\/p>\n Dabei gibt x.0 <\/b>die Version von Access an. Ein Eintrag im Schlüssel RefLibPaths <\/b>funktioniert zwar prinzipiell für jede auf einem System registrierte Komponente. Ein solcher Eintrag ist aber generell nur für den Verweis auf andere Datenbanken vorgesehen. Wenn dieser Schlüssel vorhanden ist – er muss vom Entwickler angelegt werden -, wird geprüft, ob dort ein Eintrag mit dem Namen der gesuchten Datenbank vorhanden ist. Wenn dies der Fall ist, wird der Pfad zur Datenbank aus dem Wert des Registry-Keys ausgelesen.<\/p>\n Als Drittes wird bei der Suche nach der zu ladenden Datei die SearchPath API <\/b>verwendet. Die SearchPath API <\/b>sucht nacheinander an folgenden Stellen:<\/p>\n Das Anwendungsverzeichnis ist das Verzeichnis, in dem die msaccess.exe <\/b>gespeichert ist. Da dieses Verzeichnis in der Regel im Ordner C:\\Programme <\/b>liegt, kommt es für eine eigene Bibliothek als Speicherort nicht in Frage. Das aktuelle Verzeichnis ist das Verzeichnis, das man erhält, wenn man auf Datei|öffnen <\/b>klickt. Da Sie nie genau wissen, welches das aktuelle Verzeichnis ist, kommt dieses Verzeichnis als Speicherort für eine eigene Bibliothek ebenfalls nicht in Betracht.<\/p>\n Mit dem System-Verzeichnis sind die Ordner C:\\Windows\\System <\/b>und C:\\Windows\\System32 <\/b>gemeint. Das Windows-Verzeichnis bezieht sich auf die Ordner C:\\Windows <\/b>beziehungsweise C:\\WinNT<\/b>. Dateien, die nicht das Betriebssystem betreffen, haben in diesen Ordnern generell nichts zu suchen. Hinzu kommt, dass bei neueren Betriebssystemen der angemeldete Benutzer nicht unbedingt berechtigt ist, in diesen Ordnern Veränderungen vorzunehmen. Die Dateien in diesen Ordnern werden teilweise ausgeblendet, um die Systemstabilität nicht zu gefährden. Als Speicherort für eine eigene Bibliothek sind diese Ordner daher eher ungeeignet.<\/p>\n Bei der Suche mit der Umgebungsvariablen PATH <\/b>werden alle dort eingetragenen Pfade durchsucht. Um den Pfad zu einer Bibliotheksdatenbank in dieser Umgebungsvariablen einzutragen, müssen Sie für die Weitergabe ein Installationsprogramm verwenden. Dieser zusätzliche Aufwand macht die Umgebungsvariable PATH <\/b>für eigene Bibliotheken unattraktiv.<\/p>\n Als Letztes wird das Datenbankverzeichnis durchsucht. Das Datenbankverzeichnis ist das Verzeichnis, in dem die Datenbank, die Sie gerade ausführen, gespeichert ist. Bei der Suche werden auch alle Unterordner des Datenbankverzeichnisses berücksichtigt.<\/p>\n Das Datenbankverzeichnis oder eines seiner Unterverzeichnisse bietet sich als Speicherort für eine eigene Bibliothek geradezu an. Der angemeldete User hat auf diesen Ordner auf jeden Fall die notwendigen Berechtigungen. Zusätzlich ist sichergestellt, dass der Ordner im Windows-Explorer sichtbar ist. Wenn Sie den Ordner mit der Anwendung an einen anderen Ort verschieben oder kopieren, wird auch die Bibliothek mit verschoben. Die Wahrscheinlichkeit, dass die Bibliothek an dieser Stelle gefunden wird, ist also sehr hoch.<\/p>\n Es kann Ihnen passieren, dass Sie eine neue Version Ihrer Bibliothek im Datenbankverzeichnis gespeichert haben und trotzdem eine alte Version Ihrer Bibliothek verwendet wird. Prüfen Sie dann alle hier vorgestellten Speicherorte darauf hin, ob dort eine alte Version Ihrer Bibliothek gespeichert ist. Es wird nämlich die Version Ihrer Bibliothek verwendet, die Access zuerst findet.<\/p>\n Fehlermeldungen und Symptome<\/b><\/p>\n Als Nächstes werden Fehlermeldungen und Symptome aufgezeigt, die bei Fehlern in den Verweisen auftreten. Wenn Sie die auftretenden Fehler nachvollziehen wollen, starten Sie die Beispieldatenbank mit dem Namen Demo.Fehlermeldungen.mdb<\/b>.<\/p>\n öffnen Sie als Erstes das Formular frm_Personen<\/b>. Sie erhalten in Access 2003 einen Hinweis mit dem Text: „Ihr Projekt enthält einen fehlenden oder inkorrekten Verweis auf die Datei „xxx“. Sie haben die Möglichkeit, sich zusätzliche Hilfe zu diesem Fehler anzeigen zu lassen.“ Dieses Hinweisformular zeigt Ihnen deutlich, dass es ein Problem mit den Verweisen gibt, und informiert Sie, was Sie zur Bereinigung dieses Problems tun können. Wenn Sie das Formular öffnen, sehen Sie im Feld Initialen statt des erwarteten Feldinhalts den Text #Name <\/b>wie in Bild 3. In diesem Feld werden die Initialen mittels der Funktion Links <\/b>aus den Feldern Vorname <\/b>und Nachname <\/b>ermittelt.<\/p>\n Bild 3: Der Eintrag #Name in einem Steuerelement deutet auf ein Problem mit den Verweisen hin.<\/span><\/b><\/p>\n Die Funktion Links <\/b>beziehungsweise Left <\/b>ist eine Funktion aus der Bibliothek VBA<\/b>. Diese Bibliothek wird als Letztes durchsucht. Da vorher eine andere Bibliothek nicht gefunden werden kann, bricht der Prozess der Disambiguation ab und Access reagiert mit einem Fehler.<\/p>\n Wenn Sie als Nächstes eine der beiden Schaltflächen anklicken, wechselt Access in den VBA-Editor. Dort erscheint eine Fehlermeldung mit dem Text Fehler beim Kompilieren: Projekt oder Bibliothek nicht gefunden<\/b>. Der Befehl Left <\/b>ist im VBA-Editor gelb markiert.<\/p>\n Wählen Sie nun im VBA-Editor den Befehl Debuggen|Kompilieren von… <\/b>aus. Sie erhalten dieselbe Fehlermeldung wie vorher. Wieder ist das Schlüsselwort Left <\/b>gelb markiert. Wenn Sie die Meldung mit OK <\/b>bestätigen, öffnet sich zusätzlich der Verweis-Dialog.<\/p>\n öffnen Sie als Nächstes das Formular mit dem Namen frm_Recordset <\/b>und klicken Sie dort auf die Schaltfläche Test<\/b>. Sie erhalten die Fehlermeldung mit dem Text Laufzeitfehler 13: Typen unverträglich<\/b>. Klicken Sie jetzt auf Debuggen <\/b>und Sie landen im VBA-Editor. Dort ist die problematische Codezeile markiert. Das Problem hier liegt darin, dass ein Objekt vom Typ Recordset <\/b>deklariert wurde. In den Verweisen hat die Bibliothek ADO <\/b>Priorität vor der Bibliothek DAO<\/b>. Im Code wird dann eine Methode aus der DAO<\/b>-Bibliothek verwendet. <\/p>\n Die nächsten beiden Fehlermeldungen können ihre Ursache in fehlenden OCX-Steuerelementen haben:<\/p>\n Manuelle Lösungen<\/b><\/p>\n Nachdem jetzt klar ist, wie sich Fehler in den Verweisen auswirken, sollen Wege aufgezeigt werden, um diese Probleme zu lösen.<\/p>\n Wenn Sie einen Fehler in den Verweisen vermuten, gehen Sie wie folgt vor:<\/p>\n öffnen Sie den VBA-Editor (ALT + F11<\/b>). öffnen Sie dort den Verweis-Dialog (Extras|Verweise<\/b>). Prüfen Sie, ob Sie einen Verweis finden, vor dessen Namen NICHT VORHANDEN <\/b>steht (siehe Bild 4). Entfernen Sie den defekten Verweis, indem Sie ihn abwählen. Prüfen Sie als Nächstes, ob der Verweis überhaupt benötigt wird. Wählen Sie dazu im VBA-Editor Extras|Debuggen von… <\/b>aus.<\/p>\n Bild 4: Einen defekten Verweis erkennen Sie an dem Hinweis NICHT VORHANDEN vor seinem Namen.<\/span><\/b><\/p>\n Gibt es keine Fehlermeldung, wird der Verweis nicht benötigt und das Problem sollte gelöst sein. Wenn beim Debuggen eine Fehlermeldung erscheint, wechseln Sie erneut in den Verweis-Dialog und fügen den soeben entfernten Verweis wieder hinzu. Wenn Sie jetzt den VBA-Code erneut kompilieren, sollte keine Fehlermeldung mehr auftreten.<\/p>\n Es kann vorkommen, dass Sie ein Problem mit den Verweisen haben und dennoch keinen Verweis mit dem Hinweis NICHT VORHANDEN: <\/b>vor seinem Namen finden. In diesem Fall fügen Sie einen beliebigen Verweis ein und verlassen dann den Verweis-Dialog. öffnen Sie direkt danach den Verweis-Dialog wieder und entfernen Sie den soeben eingefügten Verweis.<\/p>\n Durch dieses Prozedere wird die interne Auflistung der Verweise von Access aktualisiert. Häufig kann das Problem dadurch behoben werden.<\/p>\n Sollte auch das Hinzufügen und Löschen eines Verweises nicht zum Ziel führen, bleibt Ihnen noch folgender Weg: Sie entfernen alle Verweise (bis auf VBA und Access). Jetzt schließen Sie den Verweis-Dialog. Danach öffnen Sie den Verweis-Dialog und fügen alle soeben gelöschten Verweise in der gleichen Reihenfolge wieder ein. <\/p>\n Auch durch dieses Prozedere soll die interne Auflistung der Verweise von Access aktualisiert werden.<\/p>\n Manchmal kommt es vor, dass alle bisher vorgeschlagenen Wege nicht zum Ziel führen. Dann bleibt Ihnen als letzte Möglichkeit nur noch, alle Objekte in eine neue, leere Datenbank zu importieren und dort die notwendigen Verweise einzufügen.<\/p>\n Alle diese manuellen Lösungen erfordern, dass Sie den Verweis-Dialog öffnen können. Den Verweis-Dialog können Sie aber nur in einer .mdb<\/b>-Datei öffnen. In einer .mde<\/b>-Datei oder in der Runtime-Version können Sie Probleme mit den Verweisen nicht auf den hier geschilderten Wegen lösen.<\/p>\n Lösungen mit VBA (I)<\/b><\/p>\n Es gibt verschiedene Möglichkeiten, auf Probleme mit den Verweisen per VBA zu reagieren. In der Beispieldatenbank mit dem Namen Demo.Lösungen.mdb <\/b>können Sie die hier vorgestellten Code-Beispiele unter Access 2002 und höher nachvollziehen und ausprobieren.<\/p>\n Die einfachste Lösung besteht darin, zu ermitteln, ob es defekte Verweise gibt. Wenn defekte Verweise gefunden werden, wird der Benutzer darüber informiert.<\/p>\n Als Erstes wird die Eigenschaft BrokenReference <\/b>geprüft. Wenn diese Eigenschaft True <\/b>zurückliefert, werden alle Verweise in einer For Each<\/b>-Schleife durchlaufen. Für jeden Verweis wird die Eigenschaft IsBroken <\/b>geprüft.<\/p>\n Im Fall eines defekten Verweises wird eine MsgBox <\/b>mit dem Namen des defekten Verweises ausgegeben.<\/p>\n Der Vorteil dieser Lösung besteht darin, dass dieser Code nicht nur in einer .mdb<\/b>-Datei, sondern auch in einer .mde<\/b>-Datei und in der Runtime-Version funktioniert. <\/p>\n Der Nachteil dieser Lösung liegt darin, dass nur auf das Problem mit einem defekten Verweis hingewiesen wird. Eine echte Lösung des Problems erfolgt nicht.<\/p>\n Lösungen mit VBA (II)<\/p>\n Die nächste Lösung stammt aus dem deutschsprachigen KB-Artikel 194374 [2]. Die Lösung besteht darin, den ersten Verweis zu löschen und ihn danach wieder einzufügen.<\/p>\n Es wird der erste Verweis ermittelt, der nicht VBA oder Access ist. Der Pfad zu diesem Verweis wird in einer Variablen zwischengespeichert.<\/p>\n Danach wird der Verweis gelöscht und mit der Methode AddFromFile <\/b>wieder eingefügt. Am Ende wird mit der undokumentierten Anweisung SysCmd(504, 16483) <\/b>der VBA-Code kompiliert.<\/p>\n Mit diesem Code soll erreicht werden, dass VBA die interne Auflistung der Verweise aktualisiert. Der wesentliche Nachteil dieser Lösung besteht darin, dass diese Lösung nur in einer .mdb<\/b>-Datei funktioniert. In einer .mde<\/b>-Datei und in der Runtime können die Verweise nicht bearbeitet werden.<\/p>\n Ein weiterer Nachteil ist, dass die Reihenfolge der Verweise geändert wird. Der Verweis, der entfernt wird, hat nach dem Einfügen die niedrigste Priorität. Und schließlich muss sich die verwiesene Datei auch an dem Ort befinden, wo sie ursprünglich lag.<\/p>\n Lösungen mit VBA (III)<\/b><\/p>\n Die folgende Lösung stammt aus dem englischsprachigen KB-Artikel 194374 [3]. Dort wird vorgeschlagen, alle defekten Verweise zu löschen und diese anschließend wieder einzufügen.<\/p>\n In einer Schleife werden alle Verweise durchlaufen. Wenn ein defekter Verweis gefunden wird, wird der Pfad zum Verweis in einer Variablen zwischengespeichert. Der Verweis wird dann gelöscht und mit der Methode AddFromFile <\/b>wieder eingefügt.<\/p>\n Die Nachteile dieser Lösung sind die gleichen wie beim vorhergehenden Vorschlag. Diese Lösung funktioniert nur in einer .mdb<\/b>-Datei. Außerdem wird die Reihenfolge der Verweise geändert. <\/p>\n Lösungen mit VBA (IV)<\/b><\/p>\n Die nächste Lösung versucht einige Nachteile der vorherigen Lösungen zu beseitigen.<\/p>\n In einer Schleife werden alle Verweise durchlaufen. Für alle nicht eingebauten Verweise wird geprüft, um welche Art von Verweis es sich handelt. Bei einer Type Library wird deren Guid ermittelt. Bei einer Bibliotheksdatenbank wird der Pfad ermittelt. Als Nächstes wird der jeweilige Verweis gelöscht und mit der passenden Methode wieder eingefügt.<\/p>\n Dadurch, dass alle Verweise gelöscht und wieder eingefügt werden, wird die ursprüngliche Reihenfolge der Verweise nicht verändert.<\/p>\n Bei der Methode AddFromGuid <\/b>wird für die Version der Type Libraries jeweils 0, 0 <\/b>als Parameter verwendet. Dadurch wird erreicht, dass die jeweils aktuellste Version auf dem Rechner eingesetzt wird. Auch diese Lösung hat den Nachteil, dass sie nur in einer .mdb<\/b>-Datei funktioniert.<\/p>\n Weitere Lösungsansätze<\/b><\/p>\n Die vorgestellten Code-Beispiele haben gezeigt, dass es keinen (einfachen) Weg gibt, um Probleme mit den Verweisen per VBA zu bereinigen.<\/p>\n Um das Thema defekte Verweise haben sich bereits viele clevere Leute Gedanken gemacht. So finden Sie unter [4] einen Artikel von Michael „MichKa“ Kaplan. Er beschreibt dort in zehn Punkten, wie er vorgehen würde, um sicherzustellen, dass Verweise in einer Anwendung funktionieren. Sein Plan wurde zwar bei Microsoft wegen der zu erwartenden Performanceeinbußen nicht umgesetzt. Es lohnt sich aber auf jeden Fall, diesen Artikel zu lesen. Man kann dort viel über Verweise lernen.<\/p>\n Die ehemaligen Access MVPs Terry Kreft und Dev Ashish haben mit ihrem References Wizard <\/b>ein kleines, aber feines Tool für defekte Verweise veröffentlicht. Sie finden dieses Tool unter [5]. <\/p>\n Sie können den References Wizard <\/b>als Add-In installieren. Sie können aber auch dafür sorgen, dass das Fenster des Wizards bei defekten Verweisen direkt beim Start Ihrer Anwendung geöffnet wird. Sie finden im References Wizard <\/b>eine Liste der in Ihre Anwendung eingebundenen Verweise (siehe Bild 5). Zum jeweils markierten Verweis können Sie diverse Details im unteren Teil des Fensters finden.<\/p>\n Bild 5: Der References Wizard gibt einen detaillierten überblick über die eingebundenen Verweise<\/span><\/b><\/p>\n Außerdem erlaubt es der References Wizard<\/b>, defekte Verweise zu reparieren oder zu entfernen. Zusätzlich haben Sie Zugriff auf den Pfad RefLibPaths <\/b>in der Registry. Leider funktioniert der Wizard in einer .mde<\/b>-Datei nur teilweise.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Dieser Beitrag hat Ihnen gezeigt, wie Access und VBA vorgehen, um die richtige Bibliothek für einen Befehl zu finden. Sie wissen jetzt auch, wie Sie Access bei diesem Prozess unterstützen können. Außerdem haben Sie erfahren, wie es zu defekten Verweisen kommt und wie sie sich auswirken. Schließlich wurden manuelle Lösungen und Lösungen per VBA aufgezeigt.<\/p>\n An dieser Stelle ist es Zeit für ein kleines Fazit: Verweise erleichtern die Arbeit beim Programmieren. Das hat Ihnen der erste Beitrag dieser Reihe gezeigt. Verweise schaffen aber im Gegenzug auch eine gewisse Abhängigkeit von dem Rechner, auf dem Ihre Access-Anwendung ausgeführt wird. Je mehr Verweise Sie verwenden, desto größer wird diese Abhängigkeit.<\/p>\n Dieser Beitrag hat deutlich gemacht, dass Sie Probleme mit den Verweisen mit VBA nur bedingt beseitigen können. Aus den oben dargestellten Gründen ist der Schluss zu ziehen, dass Sie am Besten auf Verweise verzichten sollten. Sie vermeiden damit mögliche Probleme.<\/p>\n Welche Möglichkeiten Sie haben, ohne einen Verweis auf eine externe Bibliothek zuzugreifen, erfahren Sie im nächsten Beitrag. Dort wird es um Early- und Late-Binding gehen.<\/p>\n Quellen:<\/p>\n [1] KB 824255: So löst Access VBA-Verweise auf: http:\/\/support.microsoft.com\/kb\/824255\/de<\/p>\n [2] KB 194374 (de): http:\/\/support.microsoft.com\/kb\/194374\/de<\/p>\n [3] KB 194374 (en): http:\/\/support.microsoft.com\/kb\/194374\/en-us<\/p>\n [4] Gedanken von M. Kaplan: http:\/\/www.trigeminal.com\/usenet\/usenet026.asp1033<\/p>\n [5] Verweis-Checker von D. Ashsih und T. Kreft: http:\/\/www.mvps.org\/access\/modules\/mdl0022.htm<\/p>\n Enthaltene Beispieldateien:<\/p>\n Verweise.zip<\/p>\nIf VBA.Left$(Me!txtName,1)=\"M\" Then<\/pre>\n
Access.Application.Run<\/pre>\n
basMyModul.MyFunction<\/pre>\n
MyLib.MyFunction<\/pre>\n
MyLib.basMyModul.MyFunction<\/pre>\n
'Deklaration ohne Bibliothek<\/pre>\n
Dim rst As RecordSet<\/pre>\n
'Deklaration mit Bibliothek<\/pre>\n
Dim rst As DAO.RecordSet<\/pre>\n
![\"missing](\"..\/fileadmin\/_temp_\/2008_02\/VerweiseIII-web-images\/Bild377_opt.jpeg\")
<\/p>\n![\"missing](\"..\/fileadmin\/_temp_\/2008_02\/VerweiseIII-web-images\/Bild384_opt.jpeg\")
<\/p>\n\n
\n
HKLM\\Software\\Microsoft\\Office\\x.0\\Access<\/pre>\n
\n
![\"missing](\"..\/fileadmin\/_temp_\/2008_02\/VerweiseIII-web-images\/Bild404_opt.jpeg\")
<\/p>\n\n
![\"missing](\"..\/fileadmin\/_temp_\/2008_02\/VerweiseIII-web-images\/Bild416_opt.jpeg\")
<\/p>\n Dim ref As Access.Reference<\/pre>\n
Dim strHinweis As String<\/pre>\n
If Application.BrokenReference = True Then<\/pre>\n
For Each ref In Application.References<\/pre>\n
If ref.IsBroken Then<\/pre>\n
strHinweis = "Verweis " & ref.Name _\r\n & " defekt!"<\/pre>\n
VBA.MsgBox strHinweis, _<\/pre>\n
vbCritical, "Achtung:"<\/pre>\n
End If<\/pre>\n
Next<\/pre>\n
End If<\/pre>\n
Dim r As Reference<\/pre>\n
Dim r1 As Reference<\/pre>\n
Dim s As String<\/pre>\n
For Each r In Application.References<\/pre>\n
If r.Name <> \"Access\" And _<\/pre>\n
r.Name <> \"VBA\" Then<\/pre>\n
Set r1 = r<\/pre>\n
Exit For<\/pre>\n
End If<\/pre>\n
Next<\/pre>\n
s = r1.FullPath<\/pre>\n
References.Remove r1<\/pre>\n
References.AddFromFile s<\/pre>\n
Call SysCmd(504, 16483)<\/pre>\n
Dim loRef As Access.Reference<\/pre>\n
Dim intCount As Integer<\/pre>\n
Dim intX As Integer<\/pre>\n
Dim blnBroke As Boolean<\/pre>\n
Dim strPath As String<\/pre>\n
intCount = Access.References.Count<\/pre>\n
For intX = intCount To 1 Step -1<\/pre>\n
Set loRef = Acess.References(intX)<\/pre>\n
With loRef<\/pre>\n
blnBroke = .IsBroken<\/pre>\n
If blnBroke = True Or Err <> 0 Then<\/pre>\n
strPath = .FullPath<\/pre>\n
With Access.References<\/pre>\n
.Remove loRef<\/pre>\n
.AddFromFile strPath<\/pre>\n
End With<\/pre>\n
End If<\/pre>\n
End With<\/pre>\n
Next<\/pre>\n
Set loRef = Nothing<\/pre>\n
Call SysCmd(504, 16483)<\/pre>\n
Dim ref As Access.Reference<\/pre>\n
Dim strGUID As String<\/pre>\n
Dim strPfad As String<\/pre>\n
Const cTpyeLib As Long = 0<\/pre>\n
For Each ref In References<\/pre>\n
If ref.BuiltIn = False Then<\/pre>\n
If ref.Kind = cTpyeLib Then<\/pre>\n
strGUID = ref.Guid<\/pre>\n
References.Remove _<\/pre>\n
References(ref.Name)<\/pre>\n
References.AddFromGuid _<\/pre>\n
strGUID, 0, 0<\/pre>\n
Else<\/pre>\n
strPfad = ref.FullPath<\/pre>\n
References.Remove _\r\n References(ref.Name)<\/pre>\n
References.AddFromFile strPfad<\/pre>\n
End If<\/pre>\n
End If<\/pre>\n
Next ref<\/pre>\n
Call SysCmd(504, 16483)<\/pre>\n
![\"missing](\"..\/fileadmin\/_temp_\/2008_02\/VerweiseIII-web-images\/Bild422_opt.jpeg\")
<\/p>\nDownloads zu diesem Beitrag<\/h3>\n