Nutzen von .references einer externen Datenbank unter Off2010

[paulimieze]

Guten Tag zusammen,
bei einem Kunden läuft etliches noch unter 2010.

In einer Art "Service-DB" sollen Verweise einer auszuwählenden DB geprüft werden.
Ich entwickle unter 2016 und habe das Problem dort gelöst.
Unter 2010 ist mir aufgefallen (Code auf das Wesentliche reduziert, funktioniert unter 2016)):

Code [Auswählen] Erweitern

Dim db As DAO.Database
Dim ref As DAO.Reference
Dim srefName As String
Dim brefFound As Boolean
Dim vbproject As VBIDE.vbproject       
    If psDBName & "" = "" Then
        Set db = CurrentDb
    Else
        Set db = DBEngine.Workspaces(0).OpenDatabase(CurrentProject.Path & "\" & psDBName)
        Set vbproject = GetVBProject(CurrentProject.Path & "\" & psDBName)
    End If
   
    brefFound = False
    For Each ref In References 'db.References gibt Kompilierungsfehler "Methode oder Datenobjekt nicht gefunden"
       ' Debug.Print ref.Name, ref.FullPath, ref.IsBroken
        If ref.Name = refName Then
            brefFound = True
            Exit For
        End If
    Next ref
   
     For Each vbReference In References ' vbproject.References -> dito :-(
 
Das funktioniert also unter 2010 nicht für eine Fremd-DB, sowie ich über db. oder auch vbproject. gehe. Eben dieses muss ich aber für eine fremde DB tun, da ohne db. auf die eigene, aktuelle Datenbank Bezug genommen wird. Beim Zugriff auf das vbproject gilt das Gleiche; das hatte ich ausprobiert, nachdem ich diesen Fehler feststellte. Alles läuft übrigens unter DAO; die "Verzweiflungstat" ADO brachte auch kein Ergebnis.

Also zur Frage:
Kann ich - und wenn ja wie - auf die Referenzen einer beliebigen Datei zugreifen, wenn der Weg über db.references und vbproject.references am kompilieren scheitert?

Danke & Schönen Tag
Dirk

[PhilS]

Ich bezweifle, dass dein hier gezeigter Code überhaupt irgendwo funktioniert.

Kann ich - und wenn ja wie - auf die Referenzen einer beliebigen Datei zugreifen, wenn der Weg über db.references und vbproject.references am kompilieren scheitert?

Ja, das sollte schon gehen. - Vielleicht funktioniert dein Code ja, wenn du ein paar Fehler behebst.

Code [Auswählen] Erweitern

Dim ref As DAO.Reference Eine DAO.Reference gibt es nicht. Eine DAO.Relation würde mir als ähnlich einfallen, ist aber eine Beziehung zwischen zwei Tabellen. - Darum geht es dir ja nicht.

Code [Auswählen] Erweitern

'db.References gibt Kompilierungsfehler "Methode oder Datenobjekt nicht gefunden"DAO.Database.References gibt es nicht. Das ist, was die der Compiler mit "Methode oder Datenobjekt nicht gefunden" sagen möchte.

Code [Auswählen] Erweitern

For Each ref In ReferencesEin freistehendes References wird zu Application.References aufgelöst. In dieser Collection sind Access.Reference Objekte enthalten. Das könnte einen "Type Mismatch" Fehler geben, lässt sich aber bei der unklaren Situation btgl. DAO.Reference nicht sagen.

Außerdem wären das die Verweise der aktuellen DB, nicht in der externen, um die es dir eigentlich geht.

Code [Auswählen] Erweitern

For Each vbReference In References ' vbproject.References -> dito :-(

Wo kommt die vbReference her und was ist das?

Bei den VBIDE.VBProject.References wärst du am Ziel.  In dieser Collection sind Objekte vom Typ VBIDE.Reference enthalten.

[Knobbi38]

Hallo Dirk,

das kann so nicht funktioniert haben! Per DAO oder ADO machst du auf eine accdb Datei "nur" einen Datenbankzugriff und kommst so natürlich nur an darin enthaltene Daten. Wenn du auf den Code oder anderes zugreifen möchtest, mußt du die accdb als Referenz einbinden oder du öffnest die Datei per Automation.

Gruß
Knobbi38

[paulimieze]

Hallo PhilS, hallo Knobbi38,
beide habt ihr natürlich sowas von Recht:
Habe ich es doch tatsächlich geschafft, auch noch die auch unter 2016 wirklich nicht funktionierende Version zu posten...
Dass ich immer nur in meiner aufrufenden und nicht der geladenen DB landete, hatte ich ja gemerkt.
Der entscheidende Hinweis war, erst die zu bearbeitende Datei als Verweis einzubinden.
Da ist wohl an der Funktion "GetVBObject" noch was faul, es kam kein Fehler  - darum geht es aber jetzt nicht.

Um die ganze Sache zu überspringen: Nun hat es soweit funktioniert und ich stellte begeistert fest, dass ich einen "IsBroken"-Verweis per VBA nicht löschen kann; schon beim "FullPath" gibt's Runtime-Error.

Der Hintergrund des Ganzen war:
Konvertiere alte 97er MDB nach ab 2013 lesbarer Variante. 2010 war zum Lesen der MDB also die letzte mögliche Version.
Daher sollte der Ablauf sein:
- Konvertiere mdb nach accdb
- öffne accdb und entferne z.B. nicht verfügbaren "UTILITY.MDA"-Verweis

Da das nicht funktioniert (?) - siehe oben, oder gibt es doch eine VBA-Lösung zum Entfernen von "IsBroken"-Verweisen? - habe ich das Entfernen in die zu konvertierende MDB verlagert.
Da ist der Verweis ja noch nicht "IsBroken" und lässt sich daher auch per VBA entfernen.
Das Vorgehen war also in der Reihenfolge umzusortieren.

Bleibt die Frage: Kann man "IsBroken"-Verweise wirklich nicht per VBA löschen, sondern nur über den "Verweise"-Dialog? Bei wie in diesem Fall mehreren hundert MDBen bzw. dann ACCDBen macht das ja nun wirklich keinen Spaß!

Danke & Liebe Grüße
Dirk

[Knobbi38]

Hallo Dirk,

ich verstehe jetzt nicht, wo das Problem ist. Wenn du die Datenbanken per Automation öffnest und dann auf das Projekt zugreifst, kannst du doch alle Referenzen anzeigen bzw. isBroken abfragen. Das References.Objekt enthält eine Remove Methode und die soll nicht funktionieren? Eventuell braucht man noch die Zugriffsrechte auf das VB-Projekt.

Gruß
Knobbi38

[paulimieze]

Hallo, Knobbi38,
ja, das geht wohl ohne Weiteres tatsächlich nicht:
"Wenn die IsBroken-Eigenschafttrue ist, generiert Microsoft Access einen Fehler, wenn Sie versuchen, die Eigenschaften Name oder FullPath zu lesen."
Das stammt von der MS-VBA-Referenz und schließt das Löschen eines Verweises mit ein.
Steht da zwar nicht, ist aber in der Realität so.

Gruß,
Dirk

[Knobbi38]

Hallo Dirk,

es kommt auf den Kind an. Wenn es ein Access-Projekt ist, kann man sehr wohl auf die Properties zugreifen, aber für eine ext. Typelib oder Exe geht das wohl nicht. Was geht ist aber gehen müsste ist der Zugriff auf die GUID und wenn die bekannt ist, kann man sich auf die suche machen, z.B. in dem man alle Referenzen in einer versteckten Tabelle spiegelt.

Hier mal ein Link mit vielen Information, vielleicht hilft es ja?
https://groups.google.com/g/microsoft.public.access.modulesdaovba/c/JtgktQgkRi8

Gruß
Knobbi38

[markusxy]

Wenn die IsBroken-Eigenschafttrue ist, generiert Microsoft Access einen Fehler, wenn Sie versuchen, die Eigenschaften Name oder FullPath zu lesen

Ich würde davon ausgehen, dass Access den Pfad zur Laufzeit bei der Windows Registry abholt.
Alles andere würde das Prinzip der Registry ad absurdum führen.

Wenn in der Registry aber nichts gefunden werden kann, gibt's auch keine weiteren Infos.
Das Thema war aber doch das Löschen einer Referenz, die nicht aufgelöst werden kann.
Und trotz aller Hilfen, gehst du nicht mal darauf ein, ob das nun funktioniert.

Und du zeigst jetzt nicht mal den Code der angeblich funktioniert, sondern nur einen Code nach dem Trial & Error Prinzip, dessen Entwickler wohl mit den Grundlagen des Programmierens auf Kriegsfuß steht.

[paulimieze]

Und trotz aller Hilfen, gehst du nicht mal darauf ein, ob das nun funktioniert.
...
, dessen Entwickler wohl mit den Grundlagen des Programmierens auf Kriegsfuß steht.

Schrieb ich doch:
- Der entscheidende Hinweis war, die zu bearbeitende Datei erst einmal selbst in die Verarbeitungs-DB als Verweis einzubinden.
- Einen "IsBroken"-Verweis bekam ich trotzdem nicht mit "remove" entfernt.
- Das Problem wurde auf die zu konvertierende Original-MDB verlagert und für mich damit gelöst.
Ggf. könnte ich noch der durchaus korrekten Behauptung von knobbi38 nachgehen, dass man die GUID trotzdem erhält.

Ansonsten danke für die Ferndiagnose meiner Fähigkeiten.

Apropos danke:
Mit dem genannten Hinweis von knobbi38 ist das ursprüngliche Problem - Zugriff auf die Referenzen einer Fremd-DB - also erledigt.

Gruß,
Dirk

[markusxy]

Der entscheidende Hinweis war, die zu bearbeitende Datei erst einmal selbst in die Verarbeitungs-DB als Verweis einzubinden.

Das kannst du vergessen - es funktioniert nur per Automatisation.
Das Einbinden per Verweis macht man um die Methoden/Klassen der anderen Anwendung nutzen zu können, aber nicht um eine Anwendung zu reparieren.