System-DSN vs. Benutzer-DSN

14253
waldrumpus

Auf jedem neuen Computer in meinem Unternehmen wird der gleiche Softwareinstallationsprozess durchgeführt. Ein Programm muss insbesondere ü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 einfach die ODBC-Verbindung als System-DSN eingerichtet . Egal welcher Benutzer sich angemeldet hat, die Verbindung würde für ihn funktionieren und meine Arbeit wurde erledigt.

In letzter Zeit bekommen wir immer mehr Windows 7-Maschinen, und diese Methode scheint nicht mehr zu funktionieren. Das Programm erkennt die Verbindungen, die ich im System-DSN eingerichtet habe, nicht, aber die im Benutzer-DSN . Mein Problem dabei ist, dass ich jedes Mal, wenn sich ein Benutzer zum ersten Mal an einem Computer anmeldet, einen Anruf erhält und seinen eigenen DSN installieren muss.

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

Update: Der Grund ist vielleicht nicht Windows 7, sondern die Tatsache, dass auf den neuen Computern ein 64-Bit-Betriebssystem ausgeführt wird. Ich sage das, weil beim Ausführen einer Testanwendung ( Quellcode hier ) unter 64-Bit-Windows 7 der Zugriff auf den Benutzer-DSN einwandfrei funktionierte, der Zugriff auf den System-DSN jedoch die folgende Fehlermeldung ergab:

IM014: Der angegebene DSN enthält einen Architekturkonflikt zwischen Treiber und Anwendung

Die Microsoft-Dokumentation weist darauf hin, 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, da auf die System-DSN zugegriffen werden konnte, wenn ich die Testanwendung auf 64-Bit umstellte.

Die Frage ist jetzt: Warum passiert das für System-DSN, nicht aber für Benutzer-DSN - sind für die beiden unterschiedliche Treiber installiert? Das würde bedeuten, dass ich den System-DSN nicht mehr verwenden kann, da ich keinen Einfluss auf die zu verwendende Software habe.

7

2 Antworten auf die Frage

7
harrymc

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

Verwenden Sie zur Verwaltung 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 Verwaltung auf einem 64-Bit-Windows 8-Betriebssystem gibt es Symbole für das 32-Bit- und das 64-Bit-ODBC-Datenquellenadministrator-Dialogfeld.

Wenn Sie die 64-Bit-Datei "odbcad32.exe" zum Konfigurieren oder Entfernen eines DSN verwenden, der eine Verbindung zu einem 32-Bit-Treiber herstellt, z. B. "Driver to Microsoft Access" (* .mdb), wird die folgende Fehlermeldung angezeigt:

Der angegebene DSN enthält einen Architekturkonflikt zwischen Treiber und Anwendung

Um diesen Fehler zu beheben, verwenden Sie 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?

Nein, habe ich nicht; Ich hatte keine Ahnung, dass es zwei Versionen gab. Ich bin hin und weg - es funktioniert. Vielen Dank! waldrumpus vor 11 Jahren 0
Entschuldigung, ich habe die Kopfprämie nicht früher ausgeteilt. Ich dachte, dies würde automatisch passieren, wenn Sie Ihren Beitrag als akzeptierte Antwort markieren. waldrumpus vor 11 Jahren 0
Ich denke nicht, dass dies unter Windows 7 64 Bit mehr nötig ist. Durch Ausführen einer der beiden Versionen wird dieselbe Konsole mit denselben definierten DSNs aufgerufen. Ich benutzte einfach den Run-Dialog und tippte "odbcad32.exe" ein, um einen DSN zu definieren. Ich konnte auf den DSN über meine Skriptsprachen zugreifen. AndrewPK vor 11 Jahren 0
@AndrewPK: Auf dem Poster wurde Windows 7 64-Bit ausgeführt. harrymc vor 11 Jahren 0
0
Egal

User Rights: Be sure, that the User has the ability to access the System-DNS or User-DNS. The situation here was, that Lotus-Notes ran as a service under the SYSTEM-User. There was no connectivity to ODBC. We changed the User for the Service and that solved the Problem.

Verwandte Probleme