VB-Prüfen ob DAO installiert korrekt ist

Von: , Frage gestellt am Mi, 19. Jul 2000

Um zu checken, ob DAO 3.5 oder 3.6 installiert ist, habe ich mir folgenden Weg überlegt:

Dim dbe as Object
Set dbe = CreateObject("DAO.DBEngine.36")
If dbe Is Nothing Then
'kein 3.6 installiert, 3.5 versuchen
Set dbe = CreateObject("DAO.DBEngine.35")
End If
If dbe Is Nothing Then
'Kein DAO installiert
End If

Das funktioniert auch auch Computern, auf denen Access 97 oder 2000 installiert ist. Auf einem anderen Rechner ist aber von einem anderen Programm DAO installiert (kein Access drauf), dort versagt die Routine. Wenn ich aber einen Verweis auf DAO setze statt CreateObject zu benutzen, gibt´s kein Problem, also musses ja im Prinzip doch irgendwie korrekt installiert sein.

Weiss jemand, woran das liegen kann? Was genau muss denn DAO-mässig installiert sein, damit das CreateObject funktioniert?
Uni

5 Antworten zu dieser Frage

  1. Antwort von nach 12 Stunden hilfreich
    'Drum prüfe, wer sich bindet...'

    Hallo Andreas

    DAO ist u.a. eine COM - Schnittstelle. Jedes COM Objekt ist also auf dem lokalen Rechner unter HKEY_CLASSES_ROOT zu finden. Z.B. für DAO 3.51 ist auf diesem Rechner eingetragen:
    Schlüssel:
    DAO.DBEngine.35
    REG_SZ:
    Microsoft DAO 3.51 Object Library DBEngine

    Grüsse Peter

    • Antwort von nach einem Tag hilfreich
      Re: 'Drum prüfe, wer sich bindet...'

      Schlüssel:
      DAO.DBEngine.35
      REG_SZ:
      Microsoft DAO 3.51 Object Library DBEngine
      Das ist auch der Fall. Trotzdem geht das CreateObject nicht - mit Verweis funktioniert DAO aber. Es muss also irgendwelche abhängigen Schlüssel geben, die fehlen und das CreateObject fehlschlagen lassen. Wahrscheinlich kann man sich da den Wolf suchen...
      Uni

      • Antwort von nach einem Tag hilfreich
        Oops

        Salü Andreas

        Entschuldige bitte das Missverständnis. Ich meinte, Du wolltest prüfen, ob DAO installiert ist. Ich meinte, dass wenn die COM-Komponente korrekt installiert (GUID erstellt) ist, sollte auch die Befehle Create/GetObjekt funktionieren. Mir ist kein Parameter in COM bekannt, der das differenziert. Zur Sicherheit werde ich heute Abend meinen Bücherschrank befragen...

        Ganz andere Frage. Weshalb den der Ansatz mit CreateObject?
        Ich habe mit diesen DB-Objektmodellen immer mit Verweisen gearbeitet.
        Zweite Frage: wenn Du Dein Programm installierst, kannst Du nicht zur Sicherheit die DAO-Schnittstelle darüber installieren?

        Grüsse Peter

        • Antwort von nach einem Tag hilfreich
          Re: Oops

          Hallo Peter Ich meinte, dass wenn
          die COM-Komponente korrekt installiert (GUID erstellt) ist,
          sollte auch die Befehle Create/GetObjekt funktionieren.
          Ja, das dachte ich eigentlich auch und finde den Sachverhalt auch ziemlich unlogisch. Ganz andere Frage. Weshalb den der Ansatz mit CreateObject?
          Ich habe mit diesen DB-Objektmodellen immer mit Verweisen
          gearbeitet.
          Weil es nur eine ActiveX-DLL ist, die als Zusatz für Access 97/2000 gedacht ist. Und da das eine 3.5 und das andere 3.6 installiert, wollte ich damit sicherstellen, die richtige DAO-Version zu verwenden. Zweite Frage: wenn Du Dein Programm installierst, kannst Du
          nicht zur Sicherheit die DAO-Schnittstelle darüber
          installieren?
          Siehe oben. Da die DLL sowieso für Access ist wäre es "doppelt gemoppelt".

          Wäre schön, wenn dein Bücherschrank was hergibt - bin leider am Ende mit meinem Latein.
          Uni

Keine passende Antwort gefunden? Jetzt eigene Frage stellen!