Office: VBA Zugriff auf 32 Bit Access Datenbank von 64 Bit Anwendung

Hallo Zusammen,

Seit heute habe ich folgendes Problem:

Ich habe mit Access und ProgeCad eine GIS-Anwendung erstellt. Ich greife dabei von Access aus auf ProgeCad zu und umgekehrt. Von ProgeCad aus greife ich über DAO und ADO auf eine Access 32 Bit mdb zu.

Nun hat meine Firma auf ProgeCAD 2017 upgedated und dabei ist es so, dass sich auf einem 64 Bit Windows System (Win 7 und 10) nur noch ein 64 Bit ProgeCad installieren lässt. Die declare statements habe ich angepasst, aber offensichtlich ist es nicht möglich, von einer 64 Bit Anwendung per ADO / DAO auf eine 32 Bit Access-Datenbank zuzugreifen - oder?

Leider können wir weder das 64 Bit Access installieren (fast alle Anwendungen würden nicht mehr funktionieren) noch können wir das 32 Bit progecad installieren...

Weiß jemand Rat?

Danke

:)

 

Ich habe es bisher selbst nicht probiert, aber nach meiner Einschätzung sollte das durchaus funktionieren. Soweit mir bekannt ist, ist das reine Datenbankformat dasselbe. Ich sehe daher keinen Grund, warum es nicht funktionieren sollte. - Dies aber ausschließlich beim Zugriff auf die Daten über ADO/DAO, die Automatisierung von Access wird sicherlich in dem Szenario nicht möglich sein.

 

\@sonic8,
nur für mein Verständnis:
ADODB ist ja auch eine COM Komponente. Ich habe da jetzt zu wenig Erfahrung, bin aber davon ausgegangen, dass eine 64 Bit Anwendung auch ein 64Bit ActiveX benötigt.

Heißt er müsste mit einem 64Bit ADO auf eine 32Bit Access Datei zugreifen oder wie?

Edit:
Der Zugriff auf die Daten der Tabellen sollte also möglich sein. Nur beim der Zugriff auf die Access Application gibt es ein Problem?

 

Schau Dir Olafs Beiträge in Problem with VB Office and VB6 dlls an. Umgehrt geht's auch, nur muss dafür eine entsprechende 64-Bit Entwicklungsumgebung vorhanden sein.

 

Hi!

>Ich habe mit Access und ProgeCad eine GIS-Anwendung erstellt
Hä?

>Von ProgeCad aus greife ich über DAO und ADO auf eine Access 32 Bit mdb zu
1. Es gibt keine 32Bit-MDB, eine mdb ist eine mdb.
2. Wieso mit DAO & ADO, entweder nimmt man das eine oder das andere.

> Die declare statements habe ich angepasst
Hä?

Das hier ist ja ein Access- und kein ProgeCAD-Forum. Wenn du auf Hilfe hoffst, dann erkläre doch mal, um was es geht.

Gruss
Jones

 

...###

 

Hallo Jones,

>Ich habe mit Access und ProgeCad eine GIS-Anwendung erstellt
Entscheidend ist, glaub ich vor allem, dass es sich auf beiden Seiten um vba-codes handelt. Im Falle von ProgeCAD nun um eine 64 Bit Anwendung. Ansonsten könnte ich auch Excel schreiben, das macht wenig Unterschied....

>Wieso mit DAO & ADO, entweder nimmt man das eine oder das andere.
Die Anwendung ist über Jahre gewachsen (seit 1997) und umfasst mittlerweile mehr als 200.000 Code-Zeilen. In dieser Zeit hat MS seine Politik, was die lieblings DB-Schnittstelle angeht des öfteren geändert - ja, eigentlich wäre es an der Zeit für ein Clean Up.

> Die declare statements habe ich angepasst
Hier ein Beispiel
32 Bit Vba/Anwendung:
Code:

Führt zu einer Fehlermeldung
64 Bit Vba/Anwendung:
Code:

>Das hier ist ja ein Access- und kein ProgeCAD-Forum. Wenn du auf Hilfe hoffst, dann erkläre doch mal, um was es geht.

Nun ja, zu 50% geht es um ProgeCad, zu 50% eben um Access... Im Prinzip geht es um folgende Codezeilen in ProgeCAD (die mit 32 Bit ProgeCad funktionieren):

ADO:
Code:

Die Fehlermeldung ist logisch, aber scheinbar gibt es keinen 64 Bit ODBC Treiber für Access mdb Datenbanken (jedenfalls werden bei mir nur MSSQL Treiber angezeigt)?

DAO:
Code:

Die Fehlermeldung lautet hier: Run-Time error '429':
ActiveX component can't create object


Hallo Nouba,

danke für den Link - werde mich morgen mal darein vertiefen, ist doch eine Menge zu lesen.

Hallo Kyron9000,
???

Hallo Sonic8,
möglicherweise (wahrscheinlich) sind es eher die Datenbank-Treiber? Interessanterweise funktioniert die Automation von Access (2016) zu ProgeCAD problemlos, allerdings gibt es hier auch keine DB-Zugriffe

Danke an alle

 

Da würde ich widersprechen, logischerweise kann man beides nutzen, auch parallel.
DAO ist optimiert für Jet, also für MDB/ACCDB. Über einen Workspace hat man mehrere DB's im Zugriff.
ADO hat Methoden, die DAO so nicht kennt (Getstring für Textzusammensetzung, Disconnected Recordsets und weitere).

Idealerweise wird man also kein Zugehörigkeitsbekenntnis abgeben und ausleben, sondern von beiden die Vorteile nutzen, wie von weiteren Zugriffstechniken auch.

 

Hi DM,

falls es ein anderer gewust hätte, dass es dabei um VBA geht, ich jeden Falls hatte keine Ahnung.

Hast Du es mal mit 'Microsoft.ACE.OLEDB.12.0' als Provider versucht?

Gruss
Jones

 

ad...

...nachstehendes habe ich leider überlesen und PtrSafe angeboten einzufügen, in diesem Fall leider unnötig und somit ich es wieder gelöscht habe... *Smilie

 

Klar, die muss man schon installieren. Hier ein Einstieg, ohne Anspruch auf Vollständigkeit.
https://www.microsoft.com/en-us/down...190a24fa6=True

Das ist eher ungewöhnlich. Ich glaube du solltest hierzu mal den Support der CAD-Software kontaktieren. Vielleicht können die dir auch erklären, wie du die 32bit-Version, die es ja gibt, installieren kannst.

 

\@sonic8,

das ist bei einem out of process server, was die Access-Anwendung ja darstelt, gar nicht so ungewöhnlich. Nur in process server sind auf Anwendungen der gleichen Befehlsarchitektur beschränkt.

 

Danke für die Info. Dass der Zugriff über Architekturgrenzen hinaus mit COM grundsätzlich möglich ist, war mir bewusst, aber nicht dass es in vielen Fällen, wie diesem, eigentlich "automatisch" möglich sein sollte.

Um ehrlich zu sein, ich verstehe die Mechanismen nach einer kurzen Recherche aber noch nicht wirklich vollständig.

Für den geneigten Mitleser hier ein kurzer Info-Text zu Process Interoperability von MS.

 

Hi!

Hier noch eine Info zum ACE.OLEDB - Provider (32/64 Bit):
https://datasavvy.me/2017/07/20/inst...it-processing/

Gruss
Jones

 

Hallo zusammen,

vielen Dank für eure Anmerkungen und Ratschläge. Ich habe die Anleitung aus Jones letztem Post versucht - und es funktioniert alles wie es soll - Danke!

@jones: Sorry, das mit dem Vba hab ich wirklich in meinem ersten Post vergessen - hätte nicht passieren sollen