Office: (Office 2007) ODBCDirect-Workspace in Acc2007 nicht mehr möglich

jetzt wird's lustig:

Code:

Noch etwas:
Code:

zum Glück braucht man das nicht, wenn man OpenDatabase verwendet. *wink.gif*

/edit:
Es gibt aber für die Registry-Gemeinheit eine Lösung:
dao360.dll direkt ohne Registry-Umweg verwenden. (Stichwort DirectCOM.dll)
Code:

Anm.: DirectCOM ist eine Klasse zur Kapselung der DirectCOM.dll-Methoden

 

Aber erklärst du mir mal, wie das ("Registry-Gemeinheit") geht?
Für DAO.DBEngine.36 sehe ich die CLSID {00000100-0000-0010-8000-00AA006D2EA4}.
Dort wiederum ist als InProcServer32 angegeben:
C:\Programme\Gemeinsame Dateien\Microsoft Shared\DAO\dao360.dll
(Die DAO.DBEngine.120 hat eine andere CLSID)

Also sieht es danach aus, als würde Access die DAO360.dll gar nicht laden, weil es ACE-DAO bereits geladen hat - sowas wie ein SxS Side-by-Side-Mechanismus? Die Methodenaufrufe gehen wohl direkt an die geladene ACE.
Das muss ich mir auch nochmal genauer anschauen... wenn ich aktuell nur mehr Zeit hätte... *frown.gif*

Ciao, Sascha

 

Mit "Registry-Gemeinheit", meinte ich den Weg über den Aufruf der registrierten COM-dll.
Du hast Recht, in der Registy selbst sieht alles bestens aus. (ich testete mit Vista + AC07)
Bisher ging ich immer davon aus, dass CreateObject den Eintrag in der Registry sucht und dann das COM-Objekt instanziert.
Nur: wie kommt es dann zu einem ACEDAO-Objekt?

 

Wenn ich unter VB mit
CreateObject("DAO.DBEngine.36")
eine DBEngine erzeuge, dann kommt konsequenterweise die Fehlermeldung "Nicht erkennbares Format", wenn ich eine ACCDB mit
oDBEng.OpenDatabase öffnen will.
Wenn ich das Gleiche in einem A2007-Modul (ACCDB) mache dann gibt's keine Fehlermeldung. (Alle Objektariablen nur als Object deklariert, kein Verweis!)
Heißt also, dass tatsächlich eine DAO.DBEngine.120 erzeugt wird.

Das eröffnet mir allerdings nun auch neue Horizonte, was COM unter VBA angeht... *wink.gif*

Ciao, Sascha

Nachtrag:
Kurios: Wenn ich mit der API-Funktion CLSIDFromProgID die CLSID für "DAO.DBEngine.36" oder 120 ermittle, dann wird die korrekte unter VB6 zurückgeliefert. Unter A2007/VBA ermittelt die identische Funktion in beiden Fällen eine CLSID, die es gar nicht gibt! Und zwar nach jeden Laden der DB eine neue.
(So langsam verstehe ich, warum MS solche Schwierigkeiten bei Parallelinstallation von A2007 mit Vorversionen hat...)

 

Ergänzung zu #16:
Statt die DirectCom.dll zu verwenden, geht das auch direkt per VBA, aber leider nicht ohne eine zusätzliche TypeLibrary, die die Definition von IClassFactory enthält - siehe Demo unter
http://www.moss-soft.de/public/DAO_TEST.zip
Insofern - zusätzliche Verweisdatei - ist ein nicht wirklich ein Gewinn gegenüber der DirectCOM-Geschichte. Zeigt aber immerhin, wie jene das intern wohl auch macht, bzw. allgemein, wie man Objekte direkt aus einer COM-DLL erzeugen kann. (API DLLGetCLassObject)

In Demo entweder das Formular aufrufen oder die beiden Prozeduren in mdlTest checken.

Ciao, Sascha

 

Stimmt, ist nicht wirklich ein Ersatz für DirectCOM, aber trotzdem danke für das Lehrstück. *wink.gif*
Kann man damit auch eine .net-COM-dll verwenden?
(das funktioniert nämlich mit der DirectCOM.dll nicht.)

Ich probierte gerade aus, in Ac00 eine DAO 3.5-Engine zu verwenden.
Hier wird per CreateObject("DAO.DBEngine.35") die Version 3.51 korrekt geliefert. => ist also ein neues Feature von Ac07. *wink.gif*

Unter Ac02 mit gesetztem DAO 3.6-Verweis getestet:
Code:

 

Das kommt drauf an, ob sie STDCALL DLLGetClassObject exportiert. Dann müsste es gehen.

Vielleicht auch von VBA 6.5?
Das Krasse ist ja, dass selbst mit API und CoCreateInstance auf die DBEngine36-CLSID die Engine aus der ACE erzeugt wird.
Sowas ist mir völlig neu. Keine Ahnung, wie das geht. Die dao360.dll wird ja durchaus dabei geladen, wie man im ProcessViewer sehen kann. Aber dann muss VBA irgendwie den API-Aufruf umbiegen. Ich finde in der MSDN nichts zu so einem Verhalten von CoCreateInstance.

Ciao, Sascha

 

Mit Excel 2007 bekomme ich mit CreateObject("DAO.DBEngine.36") eine 3.6er-Version.
=> Access07-Feature

 

Na gut...
Um das abzuschließen (?) übrigens noch der Hinweis, dass man einem A2007-Forumar kein JET-DAO-Recordset zuweisen kann. Es nimmt nur Recordset2, sonst kommt die Meldung: "Kein gültiges Recordset".
Spielt auch keine Rolle, ob ACCDB oder MDB.

Ciao, Sascha

 

gut, dann kratzen wir noch die Kurve zum ursprünglichen Problem *wink.gif*:
Da der Umweg über CreateObject nicht funktioniert, ist es zumindest möglich, das Problem auch ohne ADODB zu umgehen, wenn man statt
Code:

nur die Datenbank öffnet
Code:

 

Hallo Ihr Zwei,

es freut mich ja sehr das Ihr Euch über meinenm Beitrag so her macht und es Euch anscheinend Spaß macht ihn von vorne bis hinten zu zerpflücken und darüber zu fachsimpeln, was möglich wäre und was nicht. *frown.gif*

Ich meinerseits verstehe nichts mehr und bin jetzt auch nicht schlauer als vorher. Aber es ist doch nett zu sehen, dass man jemanden eine Freude gemacht hat.*mad.gif*

Abschließend noch eine Frage:*entsetzt
Ist es auf einfache Weise möglich, dass Ding ans laufen zu bekommen oder sollte es tatsächlich die alte Support-Firma umprogrammieren?

 

Das Office-Forum ist nun einmal ein Forum und keine Support-Seite. *wink.gif* Das wird aufgrund der hier angebotenen Lösungen gerne übersehen.

Definiere "einfach". Ja, ich halte es für einfach den Code umzustellen.
Eine Möglichkeit - ohne auf ADO umstellen zu müssen - zeigte ich in #25.
Ob diese Variante funktioniert, hängt aber davon ab, wie bisher ODBCDirect genutzt wurde. - Kann also nur im Gesamtkontext der Anwendung bewertet werden.
Wenn dir das Beispiel aus #25 nicht weiterhilft und du bei den Überlegungen zuvor keinen Lösungsansatz entdeckt hast, dann gibt es vermutlich nur 2 Möglichkeiten: entweder du arbeitest dich selbst in die Materie ein oder gibst es an einen Dienstleister weiter, der dich dabei unterstützt.

 

Das mit dem fachsimpeln war auch nicht bös gemeint. Es amüsierte mich halt nur, was aus so einer banalen Frage entsteht.
Nichts für ungut. Ich bin froh das es dieses Forum gibt und sich die "Profis" die Zeit nehmen und krampfhaft versuchen, Neulingen oder nicht so versierten Anwendern (wie mich) die Möglichkeiten von Access aufzuzeigen.

OK, ich werde auf die zweite Möglichkeit gehen und einen Supporter dranlassen.

Mir reicht es ja schon, dass ich mich mit dem Thema Access beschäftigen muss, obwohl es gar nicht zu meinem Aufgabengebiet gehört.
Aber jetzt auch noch so tief in die Materie einsteigen um den aufgezeigten Code komplett zu verstehen, dazu fehlt mir einfach die Zeit.

Also nochmal vielen Dank Euch beiden.