Umstellung auf 64 bit Version
#1
Hallo, wir haben ein Update bekommen und dadurch wurde unser excel und unser Access auf die 64bit Version umgestellt.

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

wir nutzen den Befehl

Set Dbank = OpenDatabase(file_dbCont)

Immer beim festlegen der Dbank kommt ein Kompilierungsfehler.
Kann uns jemand helfen, wie wie das VBA ändern müssen, damit es funktioniert?

Vielen Dank
Antworten Top
#2
Zitat:Immer beim festlegen der Dbank kommt ein Kompilierungsfehler.

Würdest du uns auch verraten, welcher?
Antworten Top
#3
Kompilierungsfehler im ausgeblendetem Modul: Steuerung
Antworten Top
#4
Moin!
Du musst den Schutz des VBA-Projekts entfernen.
Dann springt der Debugger zum Fehler, der dann analysiert werden kann.
Kompilierfehler in ausgeblendetem Modul - VBA - Automate Excel

Gruß Ralf
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. 
Lehre einen Mann zu fischen und du ernährst ihn für sein Leben. (Konfuzius)
Antworten Top
#5
Gut gemeinter Rat aus langjähriger Erfahrung:

Mecker mit Deinem Admin das er wieder die 32-Bit Version installiert, wenn der Code nicht für 64-bit geschrieben ist, dann ist eine Umprogrammierung in der Regel sehr aufwendig und manchmal nicht möglich.

Und die 64-bit Version brauchst Du erst wenn die 32-Bit im Speicher an Ihre Grenzen stößt, was in der Realität selten der Fall ist. Außerdem ist 64-Bit langsamer als 32-Bit!

Andreas.
Antworten Top
#6
Zitat:Gut gemeinter Rat aus langjähriger Erfahrung:

Mecker mit Deinem Admin das er wieder die 32-Bit Version installiert,

Das würde ich so nicht empfehlen. Denn man muss bspw. nur SAP mit Excel als Frontend für Analysen im Einsatz haben, um sehr schnell an die Grenzen der 32-VBit Version zu gelangen. 

Zu allen Problemen, die bei mir nach der Umstellung aufgetreten sind, habe ich immer schnell die richtigen Antworten bekommen. Allerdings habe ich auch immer exakt angegeben, welche Codezeile(n) das Problem verursacht haben.
Antworten Top
#7
Hallo,

die Umstellung von 32-Bit- auf 64-Bit-Systeme mag manchmal herausfordernd sein, aber wenn keine ActiveX-Komponenten genutzt werden, die nur in 32-Bit-Systemen verfügbar sind, sollte es möglich sein. Die Frage ist natürlich immer, wie es um das Know-how in der Firma steht. Wer sich für eine Umstellung entscheidet, sollte zumindest auch das Budget für die Migration der Software bzw. für die Vergabe einer externen Auftragsarbeit mit einplanen.

Knobbi38
Antworten Top
#8
Hallöchen,

ich hätte mal eine Zusatzfrage - wurde nur das Excel von 32 auf 64 bit umgestellt oder gab es da mehr, z.B. auch eine neue Excelversion, W10 zu W11, Umstellung der Anmeldetaten, oder was auch immer?

Ich habe seit Excel 5 und 97 eigentlich fast auf jede Version umstellen müssen und kann eigentlich aus dieser Erfahrung heraus berichten, dass vor allem die Versionsunterschiede Probleme bereiteten.
Das fing mal damit an, dass Makro- und Dialogblätter durch VBA und Userforms ersetzt wurden, anfangs sogar in deutsch. Ok, das ist lange her Wink
Automatisierte Prozesse wurden durch Systemänderungen gekillt, weil Sicherheitseinstellungen anders griffen. Unter WinNT lief einiges anders als unter W7, XP, ...
Die Excel-Versionen hatten von mal zu mal anderen Speicherbedarf bzw. anderes Handling. Prozesse, die mal liefen, klemmten in neueren Versionen wg. zu wenig Arbeitsspeicher. Eine Prüfung z.B. unter 2010 ergab, dass bei Kopieraktionen jedes mal etwas im Speicher zurück blieb, und bei ca. 1,2 GB war dann Schluss, Excel stürzte ab.
Klar, Kompatibilitäsprobleme gab es auch beim eingesetzten Datenbank-Treiber. Ohne Umstellung hätte man wohl auch beim 32 bit Betriebssystem bleiben müssen ...
Die Umstellung der verwendeten API war auch ein Thema.
Die Authentifizierungsmethode wurde zwischenzeitlich auch mal geändert, ich glaube, auf Kerberos.

Es ist aus meiner Sicht dann doch ein recht vielschichtiges Thema. Ich denke, wo ein Wille ist, ist auch ein Weg. (Muss nicht der kürzeste oder schnellste sein Wink )
Gewerblich ist halt' noch ein Kosten-Nutzen-Vergleich nicht zu verachten ...

Bei mir sah das Verbinden zu Oracle mal so aus
PHP-Code:
'Set objSession = CreateObject("OracleInProcServer.XOraSession")
'
Set objDatabase objSession.OpenDatabase("dbName""/"0
Wobei der Schrägstrich für die Anmeldung mit den userdaten das am PC angemeldeten Kollegen stand.

Später gab es dann das
PHP-Code:
Set Dbase = New ADODB.Connection
Dbase
.Open ("Provider=OraOLEDB.Oracle;Data Source=dbName.world;User ID=/;Password=;Persist Security Info=True;"

(Verweis auf Microsoft ActiveX DataObjects 6.1 Library - also, da kann man auch mal schauen, ob da was als nicht vorhanden markiert wird)

Aber, wie an anderer Stelle schon zu lesen, da braucht man zumindest erst mal Einblick in Deinen Code und vielleicht ein paar weitere Info's - siehe oben...
.      \\\|///      Hoffe, geholfen zu haben.
       ( ô ô )      Grüße, André aus G in T  
  ooO-(_)-Ooo    (Excel 97-2019+365)
Antworten Top
#9
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
Antworten Top
#10
Hallo,

die Zeile 
Code:
Set Dbank = OpenDatabase(file_dbCont)
kann schon aus  Prinzip nicht funktionieren, weil es so eine VBA Anweisung nicht gibt und sie damit unvollständig ist.
Du solltest zunächst „Option Explicit” an den Anfang jeder Klasse und jedes Moduls einfügen und anschließend den Quellcode vollständig kompilieren. Das muss fehlerfrei durchlaufen, erst dann kannst du mit der Fehlersuche beginnen.
Antworten Top


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste