Umstellung auf 64 bit Version

[schauan]

Hallöchen,

@Knobbi,

weil es so eine VBA Anweisung nicht gibt und sie damit unvollständig ist.

ich wäre nur mit dem zweiten Teil einverstanden. Etwas, das es nicht gibt, könnte bei mir nicht unvollständig sein Das es das gibt, sieht man in meinem Beitrag, und mit 32 bit hatte es ja funktioniert. Siehe auch der Code im hier verlinkten Beitrag. OK, wenn's die rechte Seite - nach "=" nicht gibt, wäre die linke uvo

@all
Was mir aber erst mal fehlt, ist eine Aussage, ob es bei den Verweisen das beschriebene Problemchen gibt oder auch eine Systemumstellung erfolgt ist. Ich hatte mich jetzt erst mit jemanden unterhalten, da erfolgt demnächst eine Ablösung von Windows 7 ...
Da ist vielleicht noch ein Verweis auf die 32 bit Library ... Wenn das nicht ausreicht, müsste man weiter schauen, ob es da z.B. eine ocx gibt, zum Nachinstallieren und ggf. registrieren per manuellem Eingriff in die Registry. Da ist dann vielleicht ein Einsatz eines Admin vor Ort erforderlich.

Wie schaut denn die Definition Deiner DB aus? Eventuell kann man da was erreichen. Siehe hier:
stackoverflow-dao-dbengine-class-no-longer-registered-in-ms-access-2016-using-windows-10
Vielleicht reicht auch das aus.

[Andreas Killer]

Ist ganz einfach: Dein ODBC-Treiber funktioniert nicht mit Deiner 64-bit Version.

Nochmal: Mecker Deinen Admin an das er Dir die 32-bit wieder installiert, dann läuft alles wie vorher ohne Probleme.
64-bit bringt Dir nichts außer Schwierigkeiten.

Andreas.

[DeltaX]

Bei mir funktioniert folgender Code in Excel mit einem einem 64-bit Office ohne Probleme

Code:

    Dim fileName As String
    fileName = "<path to db.accdb>"
   
    Dim db As Database
    Set db = OpenDatabase(fileName)
   
    Dim rs As Recordset
    Set rs = db.OpenRecordset("<qry or tbl>")
   
    Do While Not rs.EOF
        Debug.Print rs.Fields(1).Value
        rs.MoveNext
    Loop

Sicherer wäre 

Code:

    Dim fileName As String
    fileName = "<path to db.accdb>"
   
    Dim db As DAO.Database
    Set db = DAO.OpenDatabase(fileName)
   
    Dim rs As DAO.Recordset
    Set rs = db.OpenRecordset("<qry or tbl>")
   
    Do While Not rs.EOF
        Debug.Print rs.Fields(1).Value
        rs.MoveNext
    Loop

In Extras/Verweise habe ich einen Verweis auf "Microsoft Office 16.0 Access database engine Object Library" gesetzt

---

Hallo Zusammen, ich habe nun die Fehlermeldung gefunden, bevor ich durch das debuggen immer auf diesen Befehl komme.
Set Dbank = OpenDatabase(file_dbCont)  (dbCont) ist eine Accessanwendung)

Die Fehlermeldung lautet:

Laufzeitfehler '-2147221164(80040154)':
class not registered.


vielleicht hat jemand eine Idee woran es liegt. Beide Anwendungen (Excel & access) wurden auf 64bis umgestellt.

Danke

Ergänzung: Den Fehler kann ich in einer alten Datei, wo der Verweis auf "Microsoft DAO 3.6 Object Library" gesetzt ist, nachvollziehen. Ein Debug/Compile läuft, aber zur Laufzeit gibt es obigen Fehler.  Ersetzen von "Microsoft DAO 3.6 Object Library" durch "Microsoft Office 16.0 Access database engine Object Library" behebt den Fehler.

[knobbi38]

Hallo,

nur nochmal zur Verdeutlichung: OpenDatabase() ist keine Anweisung/Funktion von VBA, sondern muß eine Methode von einem externen Objekt sein, so wie in deinem Beispiel (#8) auch angegeben. Üblicherweise ist das in Excel das Workbooks- oder eine DAO-Objekt (DBEngine) und wie DeltaX in #13 schon beschrieben hat, ist DAO 3.6 nicht 64Bit fähig.

Der OP wird also nochmal an der 64 Bit Umstellung ein paar Anpassungen vornehmen und viel testen müssen, bevor alles rund laufen wird.

Knobbi38

[DeltaX]

Für die DAO Thematik muss er wahrscheinlich "nur" die von mir genannte Ersetzung in Extras/Verweise vornehmen.

[Andreas Killer]

Für die DAO Thematik muss er wahrscheinlich "nur" die von mir genannte Ersetzung in Extras/Verweise vornehmen.

Woher willst Du das wissen?

Ehrlich, ich verstehe Euch nicht. Der OP hat ein System was mit 32-bit einwandfrei läuft, das ist Fakt.

Wir wissen nicht ob er einen 64-bit ODBC hat und selbst wenn, wir haben nicht die geringste Ahnung ob der mit dem vorhandenen Code / Abfrage kompatibel ist. Und genau das ist der springende Punkt!

Also sollen wir den OP nun wirklich dazu ermutigen an seinem funktionieren System rumzufummeln nur damit es mit 64-bit läuft? Mit dem Effekt das es dann am Ende langsamer läuft als vorher? Ernsthaft?

Never change a running system, except you are forced to!

Andreas.

[DeltaX]

Woher willst Du das wissen?

Ehrlich, ich verstehe Euch nicht. Der OP hat ein System was mit 32-bit einwandfrei läuft, das ist Fakt.

Wir wissen nicht ob er einen 64-bit ODBC hat und selbst wenn, wir haben nicht die geringste Ahnung ob der mit dem vorhandenen Code / Abfrage kompatibel ist. Und genau das ist der springende Punkt!

Also sollen wir den OP nun wirklich dazu ermutigen an seinem funktionieren System rumzufummeln nur damit es mit 64-bit läuft? Mit dem Effekt das es dann am Ende langsamer läuft als vorher? Ernsthaft?

Never change a running system, except you are forced to!

Andreas.

Welche Mission hast Du denn?

OP schreibt

Nun haben wir in unserem VBA Probleme bei der kommunikation zwischen Excel und Access.

Also liegt die Vermutung nahe, dass er auf eine Access Datenbank zugreift. Und ich sage nicht, dass ich das weiß.
Und was der OP macht, ist noch immer dem OP überlassen.

Ansonsten meine ich, man sollte nicht diesem Ansatz folgen
Voodoo Chicken Coding

[schauan]

Hallöchen,

Never change a running system, except you are forced to!

Ich liebe diesen Spruch Ich habe in meinen Altbeständen noch einen Compaq Evo 400 mit 2000er System und Office. Da hatte ich nur den Arbeitsspeicher aufgerüstet - auf 256 MB (kein Schreibfehler, wirklich MB) und eine 10 GB Festplatte. Maximal geht lt. Hersteller WXP drauf, aber das wollte ich auch nicht umstellen, Läuft ja Bis auf die BIOS-Batterie. Wenn ich die wechsle, ist die nach einigen Monaten "Laptop im Schrank" leer. Ich komme damit sogar noch mit einem 128er WLAN-Stick ins Netz. Ist mir aber schon lange zu unsicher.
Wie gesagt, ich kenne einen der jetzt erst W7 auf ??? umstellt.
Und ich hatte einen Fall, da musste die alte Hardware bleiben. Da musste man sich ganz schön anstrengen, die hatte in Zeiten von Ethernet noch BNC als Netzwerkanschluss. Das ging ja auch, solange die Hardware mitspielte. Zur Ersatzteilversorgung wurden nach Ende des Herstellersupports ausgemusterte Geräte aufbewahrt. Die Händler, die man vorher noch per Rundruf abklappern konnte, hatten ja auch irgendwann nichts mehr - Mitte der 90er hatten auch viele angefangen, eventuelle "Rester" beim neuen ebay anzubieten Mal abgesehen von der Betreuung, weil irgendwann durch Fluktuation oder was auch immer das Wissen weg war

Ich hatte bei einer Umstellung auf W10 und Office 2010 glaube auch von DAO auf ADO umgestellt und da waren ein paar Griffe mehr notwendig als nur der Haken bei den Verweisen. Da ging es allerdings um eine Oracle-DB und wenn ich mich recht entsinne, gab es dazu neue Treiber für W10 die DAO nicht mehr unterstützten. Ist aber schon lange her. Was aber damals funktioniert hat, war eine Vorbereitungsphase, in der man die Systeme testen und umstellen konnte. Die Umstellung wurde glaube auch 2 Jahre diskutiert und angekündigt, bevor sie erfolgte. In dem Zusammenhang wurde damals auch die Hardware getauscht und auf Leasing umgestellt.

[knobbi38]

Hallo Andreas,

... except you are forced to!

das ist ja genau der springende Punkt, wenn die IT einfach eine andere Office-Version mit 64Bit installiert und vorher kein  "change request" durchgeführt wird. 

Wieso eigentlich immer ODBC? I.d.R. wird für einen Zugriff auf eine Access-DB ein OLE-DB Treiber verwendet und für JET SQL gibt es keinen Unterschied zwischen 32Bit und 64Bit, das wäre mir neu.

Knobbi38

[schauan]

Hallöchen,

Wieso eigentlich immer ODBC?

also, so was ist vielleicht auch historisch begründet und geht dann ein bisschen in die ungetouchte Richtung, dass man dabei bleibt