Seite 1 von 1

Win7 unterschiedliche Architektur von Treiber und Anwendung

Verfasst: 14. Dezember 2010, 07:34
von Thomas Reinsch
Hallo allerseits,
wir nutzen Multi User seit wenigen Monaten auf unterschiedlichen XP-Rechnern. MYSQL liegt auf einem Internetserver. Die Datenbankverbindung klappt sowohl mit dem MySQL-Connector 3.5 als auch mit 5.1.
Nun gibt es ein Problem mit einem win7-Rechner (64er). Der MySQL-Treiber 5.1 nimmt problemlos Kontakt zur Datenbank auf.
Beim Aufruf des Login-Dialogs erfolgt folgende Fehlermeldung:
"Der angegeben DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf."
Der Login-Dialog selber wird nicht weiter angezeigt.
Ein Versuch, den Treiber 3.5 zu installieren, scheiterte, vermutlich da er nicht für 64Bit Architektur gedacht ist.
Was ist zu tun?

Gruß
Thomas Reinsch

Problem gelöst

Verfasst: 20. Dezember 2010, 11:53
von Thomas Reinsch
Dieses Problem ist gelöst.
Für alle, die gleich geartete Verbindungsprobleme haben:
Der Win7-Rechner holte sich über Systemsteuerung - Verwaltung - ODBC-Quellen irrigerweise die SQL-Treiber aus der Datei C:\windows\system32\odbcad32.exe
Die richtige .exe-Datei ist aber folgende: c:\windows\sysWoW64\odbcad32.exe
Da muss man erst einmal drauf kommen.
Es reichte, die richtige Datei zu suchen, auszuführen und den Treiber zu konfigurieren .

Gruß
Thomas

Re: Win7 unterschiedliche Architektur von Treiber und Anwend

Verfasst: 31. Dezember 2011, 10:37
von peterbrinkrolf
Guten Morgen,

leider ist das Problem bei mir noch nicht gelöst... :-(. Vielleicht kann ja jemand helfen:

- MySQL ConnectorODBC 5.1 (Winx64) ist korrekt installiert, testen der Db-Verbindung erfolgreich
- Über den "regulären" Weg (Systemsteuerung -> Verwaltung -> Datenquellen (ODBC)) lässt sich der MYSQL-Treiber auswählen, alles problemlos. Nun aber der beschriebene Fehler, wenn ich eine ODBC-Verbindung aufbauen möchte: "Der angegebene DSN weist eine nicht übereinstimmende Architektur..."
- nun also gegoogelt, auf dieses Forum gestoßen, manuell den odbcad32.exe aus dem SysWOW64-Verzeichnis gestartet. Aber: Beim einrichten einer neuen Verbindung lässt sich hier der (ja eigentlich in dern 64Bit-Version korrekt installierte!) MySQL-Treiber nicht auswählen, er ist schlicht nicht vorhanden!

Hat irgendjemand irgendwelche Hilfreichen Ideen?

Vielen Dank & viele Grüße,
Peter

Re: Win7 unterschiedliche Architektur von Treiber und Anwend

Verfasst: 2. Januar 2012, 08:24
von gg
Der Datenquellen-Administrator, den Sie direkt im SysWOW64-Verzeichnis starten, listet Ihnen die installierten 32Bit-Versionen der Treiber auf. Da Sie nur eine 64Bit-Version installiert haben, wird keiner angezeigt.

Re: Win7 unterschiedliche Architektur von Treiber und Anwend

Verfasst: 5. Januar 2012, 15:32
von Saueracker
Hallo,

gg hat natürlich Recht, wenn er schreibt, dass odbcad32.exe nur die 32Bit Treiber listet, aber damit ist Peter nicht wirklich geholfen.

Der elementare Denkfehler ist wohl ein anderer: Es ist völlig egal, ob man ein 32Bit oder 64Bit Windows System verwendet. Es muss jeweils der 32Bit Treiber installiert werden, weil Untis eben "nur" ein 32Bit Programm ist und eben den dazu passenden Treiber zur Kommunikation mit der SQL Datenbank braucht.

Also: den 64Bit Treiber deinstallieren, den 32Bit Treiber installieren und wie oben beschrieben über odbcad32.exe konfigurieren, dann sollte alles klappen.

Beste Grüße
Rolf Saueracker

Re: Win7 unterschiedliche Architektur von Treiber und Anwend

Verfasst: 5. Januar 2012, 15:51
von gg
Saueracker hat geschrieben:Hallo,
Also: den 64Bit Treiber deinstallieren, den 32Bit Treiber installieren und wie oben beschrieben über odbcad32.exe konfigurieren, dann sollte alles klappen.


Die Deinstallation des Treibers an sich ist nicht erforderlich; alleinfalls ein bereits existierender Datenquellenname "gpUntis", welcher für den 64Bit-Treiber eingerichtet wurde, muss in der 64Bit-Version des Datenquellen-Administrators entfernt, bzw. umbenannt werden.

In vielen Fällen kann übrigens trotzdem die 64Bit-Version des ODBC-Treibers verwendet werden. Die bisherige Beobachtung ist die, dass es auf vielen Rechnern auch damit klappt; sollte das - wie hier - nicht der Fall sein, hat die Verwendung der 32Bit-Version des Treibers bislang immer Abhilfe geschaffen.

Re: Win7 unterschiedliche Architektur von Treiber und Anwend

Verfasst: 31. Juli 2012, 17:20
von MGA_Wrede
Hallo zusammen,

ich habe ein ähnliches Problem:
Bei 5 von 6 Computern bei uns in der Schule, bei denen der Untis-Zugang funktionieren soll, klappt es. Aber bei dem vor dem ich gerade sitze, nicht.
Folgende Situation: Hier wird bei den Clients mit Windows 7 gearbeitet. Untis verweigert den zugang wegen einer nicht passenden Architektur. Beim Datenquellenadministrator, der auf das falsche Verzeichnis zeigt, ist alles soweit korrekt eingetragen, aber das ist ja ohne Wert.
Bei dem odbcat32 in SysWOW64 ist bei Benutzer-DNS gpuntis mit dem mySQL ODBC 5.1 Treiber angegeben. Im System-DSN ist nichts verzeichnet. Die Datenquelle gpuntis kann ich aber nicht editieren, da gesagt wird, dass der Treiber nicht installiert ist. Deinstallieren kann ich diese Datenquelle auch nicht, da ich dafür den Treiber erst installieren müsste. Bei der Installation des Treibers (ich habe die 32-bit und die 64-bit Variantre versucht) wird gesagt, dass das nicht möglich sei, da schon eine neuere Version des Treibers installiert sei. Irgendwie drehe ich mich da im Kreis und weiß nicht, was ich machen soll.

Jemand hier im Forum eine Idee?
Danke im Voraus!

Re: Win7 unterschiedliche Architektur von Treiber und Anwend

Verfasst: 14. August 2012, 12:56
von MGA_Wrede
Keiner eine Idee für das Dilemma?

Re: Win7 unterschiedliche Architektur von Treiber und Anwend

Verfasst: 2. Januar 2013, 19:43
von schlootie
Hallo,
möchte dieses Thema aufgreifen, da ich Win7 64 bit neu aufsetzen musste und ich die hier oben genannte Fehlermeldung bekomme. Habe dann das gleiche Problem wie Peter, ich kann die Datei zwar ausführen, aber ja MSQL nicht aussuchen. Also geht nichts. Kann mir jemand helfen, oder geht Multiuser unter Win7 64 bit nicht?

Grüße,
schlootie

PS: Nachtrag: Problem hat sich gelöst, nachdem ich den MSQL Connector 32bit installiert und eingerichtet habe.