System-DSN vs Benutzer-DSN

Jeder neue Computer in meinem Unternehmen durchläuft den gleichen Softwareinstallationsprozess. Insbesondere ein Programm muss über ODBC auf eine MS SQL Server-Datenbank zugreifen. Das Programm wird dann von mehreren Domänenbenutzern auf demselben Computer zu unterschiedlichen Zeiten verwendet.

Auf Windows XP-Computern habe ich die ODBC-Verbindung einfach als System-DSN eingerichtet . Egal welcher Benutzer angemeldet war, die Verbindung würde für ihn funktionieren und meine Arbeit war erledigt.

In letzter Zeit erhalten wir immer mehr Windows 7-Computer, und diese Methode scheint nicht mehr zu funktionieren. Das Programm erkennt die im System-DSN eingerichteten Verbindungen nicht , jedoch die im Benutzer-DSN . Das Problem dabei ist, dass jedes Mal, wenn sich ein Benutzer zum ersten Mal an einem Computer anmeldet, ein Anruf eingeht und ich seinen eigenen DSN installieren muss.

Was ist der Grund, warum dies unter XP funktioniert, aber nicht unter 7? Habe ich es von Anfang an falsch gemacht?

Update: Möglicherweise liegt das nicht an Windows 7, sondern an der Tatsache, dass auf den neuen Computern ein 64-Bit-Betriebssystem ausgeführt wird. Ich sage dies, weil beim Ausführen einer Testanwendung ( Quellcode hier ) unter 64-Bit-Windows 7 der Zugriff auf den Benutzer-DSN einwandfrei funktioniert hat, aber beim Zugriff auf den System-DSN die folgende Fehlermeldung angezeigt wurde:

IM014: Der angegebene DSN enthält einen Architekturfehler zwischen dem Treiber und der Anwendung

Die Microsoft-Dokumentation gibt an, dass dies geschieht, wenn auf einem 64-Bit-Computer auf einen 32-Bit-Treiber zugegriffen wird oder umgekehrt. Dies könnte sehr wohl das Problem sein, denn als ich die Testanwendung auf 64-Bit umstellte, konnte auf den System-DSN zugegriffen werden.

Die Frage ist nun: Warum passiert dies für System-DSN, aber nicht für Benutzer-DSN - sind für beide unterschiedliche Treiber installiert? Das würde bedeuten, dass ich den System-DSN nicht mehr verwenden kann, da ich keinen Einfluss auf die Software habe, die wir verwenden müssen.

In dem Microsoft-Artikel zum Verwalten von Datenquellen heißt es:

Verwenden Sie zum Verwalten einer Datenquelle, die eine Verbindung zu einem 32-Bit-Treiber unter einer 64-Bit-Plattform herstellt c:\windows\sysWOW64\odbcad32.exe. Verwenden Sie zum Verwalten einer Datenquelle, die eine Verbindung zu einem 64-Bit-Treiber herstellt c:\windows\system32\odbcad32.exe. In der Verwaltung unter einem 64-Bit-Windows 8-Betriebssystem gibt es Symbole für das Dialogfeld "ODBC-Datenquellenadministrator" (32-Bit und 64-Bit).

Wenn Sie mit der 64-Bit-Datei odbcad32.exe einen DSN konfigurieren oder entfernen, der eine Verbindung zu einem 32-Bit-Treiber herstellt, z. B. Treiber für Microsoft Access (* .mdb), wird die folgende Fehlermeldung angezeigt:

Der angegebene DSN enthält einen Architekturfehler zwischen dem Treiber und der Anwendung

Verwenden Sie zum Beheben dieses Fehlers die 32-Bit-Datei odbcad32.exe, um den DSN zu konfigurieren oder zu entfernen.

Ihre Anwendung ist offensichtlich 32-Bit. Haben Sie die richtige odbcad32.exe verwendet, um den DSN zu definieren?

Benutzerrechte: Stellen Sie sicher, dass der Benutzer die Möglichkeit hat, auf das System-DNS oder das Benutzer-DNS zuzugreifen. Die Situation hier war, dass Lotus-Notes als Dienst unter dem SYSTEM-User lief. Es gab keine Verbindung zu ODBC. Wir haben den Benutzer für den Service geändert und das hat das Problem gelöst.