Verwendung von DSN + 32-Bit-Treibern

9044
Kristiaan

Ich brauche ein paar Ratschläge, da ich auf ein Problem stoße und bisher keine Lösung finden konnte.

Wir haben in MS Excel eine Reihe von Berichten entwickelt, die eine DSN-Datei verwenden, um eine Verbindung zu Datenquellen herzustellen, um Daten abzurufen. Diese funktionieren gut auf 32-Bit- und 64-Bit-Systemen.

Wir wechseln jedoch zu einer Terminalserver-Umgebung mit Windows 2008 R2 64Bit

Die Berichte können nicht mit den DSNs in dieser Umgebung ausgeführt werden, wenn nur die 32-Bit-Treiber installiert und in den ODBC-Einstellungen konfiguriert sind. Sobald wir die 64-Bit-Treiber installieren, funktioniert die Software.

Gibt es eine Methode oder Methode, um Excel oder die DSN-Datei zu erhalten, den 64-Bit-Treiber NICHT zu verwenden, sondern den 32-Bit-Treiber zu zwingen?

1

2 Antworten auf die Frage

2
ta.speot.is

Wir wechseln zu einer Terminalserver-Umgebung mit Windows 2008 R2 64Bit.

Dies verursacht an sich kein Problem, Sie müssen die 64-Bit-Version von Microsoft Office 2010 installieren. Sie müssen einen guten Grund für die Installation der 64-Bit-Version haben. Microsoft installiert die 32-Bit-Version standardmäßig auf 64-Bit-Maschinen aus einem bestimmten Grund - das Zeug funktioniert nicht mehr.

Gibt es eine Möglichkeit / Methode, um Excel oder die DSN-Datei zu erhalten, den 64Bit-Treiber NICHT zu verwenden, sondern erzwingen, dass er den 32Bit-Treiber verwendet.

Nein, aber für Konnektivität in Office-Anwendungen installieren Sie einfach die 64-Bit-Version von ACE und stellen Sie sicher, dass Ihre Verbindungszeichenfolge referenziert wird Microsoft Access Driver (*.mdb, *.accdb).

SQL Server und Oracle sowie eine ganze Reihe anderer gängiger RDBMS-Systeme verfügen über 64-Bit-ODBC-Treiber. Daher kann ich nicht erkennen, wie Sie zwischen 64-Bit-ACE und SQL Native Client / ODAC keine Verbindung herstellen können.

Wenn es immer noch nicht funktioniert, gibt es in diesem Forumsbeitrag einen allgemeinen Mechanismus für das "Proxying" von x64 -> x86 über SQL Server-verknüpfte Server . Ersetzen Sie Microsoft.Jet.OLEDB.4.0und andere Einstellungen (um es über ODBC anstelle von ODBC zu einem Verbindungsserver zu machen) durch Ihren ODBC-Provider.

Hallo Todda, vielen Dank für die Antwort zu meinem Problem. Ich wusste, dass ich 64-Bit-Treiber installieren konnte und das System auf diese Weise darauf zugreifen konnte. Allerdings testen wir derzeit unsere Systeme in TS als Proof-of-Concept, bevor wir es live einsetzen. Die Idee, die 64-Bit-Treiber neben den erforderlichen 32-Bit-Treibern installieren zu müssen, hätte dazu geführt, dass die Anwendungen erneut getestet wurden, um sicherzustellen, dass keine Kompatibilitätsprobleme zwischen den beiden Treibersätzen auftraten. Leider, ohne die Registrierungseinstellungen "basteln" zu wollen, scheint dies die einzige echte Route zu sein, also testen wir gerade. Kristiaan vor 12 Jahren 0
1
nixda

OP beantwortete seine eigene Frage

Leider gibt es keine Möglichkeit, das zu tun, was ich möchte, ohne sehr böse und nicht 100% perfekte Reg-Hacks.

Wenn Sie auf 32-Bit-ODBC-Datenquellen zugreifen müssen, muss die betreffende Anwendung 32 Bit haben.

Hier ist ein Link zu nur einem Forumbeitrag, den ich für diese Art von Problem gefunden habe. Es scheint, dass dies die einzige Möglichkeit wäre, die 64 Bit-Version von Office zu entfernen und stattdessen die 32-Bit-Version zu installieren.

http://social.msdn.microsoft.com/Forums/en-US/accessdev/thread/5108f337-f06a-4518-afe3-d3c1abd040ef/

Verwandte Probleme