32-Bit-ODBC-Zugriff auf 64-Bit-Oracle-DB

[Watson007]

ich habe hier eine Oracle 11 64-Bit-Installation auf Vista64. Nun habe ich eine Anwendung, die braucht ODBC-Zugriff auf die Datenbank, da aber die Anwendung in 32-Bit kompiliert ist und nicht als 64-Bit-Version vorliegt, werden logischerweise die 32-Bit-ODBC-Komponenten benötigt.

Nun habe ich extra die 32-Bit-ODBC-Komponenten von Oracle nachinstalliert, das hat auch soweit geklappt. Aber ich kann leider nur mit den 64-Bit-ODBC-Komponenten eine Verbindung auf Oracle herstellen, nicht mit den 32-Bit-ODBC-Komponenten (im Windows-ODBC-Programm). Dabei sind die angegebenen Parameter identisch.

Wie Ihr ja sicher wisst, ist für die 32-Bit-ODBC-Komponenten die odbcad32.exe in C:\windows\syswow64\ zuständig, und für die 64-Bit-ODBC-Komponenten die odbcad32.exe in c:\windows\system32\.
Sehr schlau von Microsoft :freak:

Also wie mache ich das jetzt? Muss ich extra noch einen 32-Bit-Listener erstellen oder so??? Kennt sich jemand damit aus? Hab auch schon gegooglet...

Also die Fehlermeldung im 32-Bit "ODBC-Administrator" lautet "ORA-12541: TNS:no Listener"
dabei sind wie gesagt die Parameter die gleichen, im 64-Bit "ODBC-Administrator" gehts mit diesen Parametern.

Achso, noch eins: client und server sind in dem Fall identisch.

Oracle macht Spaß ;D

[Watson007]

keiner eine Idee?

[Haarmann]

Ich hab den XP Modus auf Win 7 installiert bei dem gleichen Problem unterm Strich...

Ich lausche der Lösung... ich bin fast sicher, ich bin nicht alleine ;).

[Watson007]

es gibt ja den extproc(32)-Paramter in der Listener.ora, aber ich glaube das betrifft wirklich nur den Aufruf von Stored Procedures, und nicht den DB-Connect an sich.

http://publib.boulder.ibm.com/infocenter/cmgmt/v8r3m0/topic/com.ibm.cmgmtreadmefp.doc/dIO00848.htm
http://www.dbis.informatik.uni-goettingen.de/Teaching/oracle-doc/admin-guide/ch5_net.htm#CHDCDFJF

Desweiteren gibt es nur die extproc.exe unter Windows-Oracle, keine extproc32.exe... also ich glaube, das ist eher ein Linux/Unix-spezifischer Parameter.

Änderungen daran haben aber an der Fehlermeldung beim DB-Connect bei mir nichts bewirkt.

[nobex]

Dem Client ist es egal, ob der Server auf 32 oder 64 Bit läuft.

[swr1973]

Weiß nicht inwiefern es bei ODBC weiter hilft.

Wenn wir unsere 32Bit Oracle-Anwendung auf einem 64bit Betriebssystem nutzen ,müssen wir (vorausgesetzt der 32bit Oracle-Client wurde neben dem 64Bit oracle-client installiert) vor dem Start der Anwendung die 32bit-Ordner in Pfad ganz nach vorne nehmen, so dass die Anwendung dann auf die 32bit OCI.dll zugreift.

Ich weiß aber wie gesagt nicht ob das bei ODBC ähnliche Verstrickungen gibt, weil ODBC nutzen wir nicht.

[Haarmann]

swr1973

Die Idee klingt für mein Problem gut ;).

Danke

Das beschleunigt zwar dies lausige tool nicht, aber immerhin erspart es den XP Modus.

[Watson007]

Weiß nicht inwiefern es bei ODBC weiter hilft.

Wenn wir unsere 32Bit Oracle-Anwendung auf einem 64bit Betriebssystem nutzen ,müssen wir (vorausgesetzt der 32bit Oracle-Client wurde neben dem 64Bit oracle-client installiert) vor dem Start der Anwendung die 32bit-Ordner in Pfad ganz nach vorne nehmen, so dass die Anwendung dann auf die 32bit OCI.dll zugreift.

Ich weiß aber wie gesagt nicht ob das bei ODBC ähnliche Verstrickungen gibt, weil ODBC nutzen wir nicht.

das hatte ich schon getestet, der pfad für den 32-bit-client liegt in der PATH-Variable von Windows vorne ;) Aber ich habe auch mal versucht die 64-bit-dlls, die für odbc benutzt werden, umzubenennen. Anschließend lief die Verbindung im 64-bit-odbc-programm nicht mehr, und im 32-bit-odbc-programm wars so wie vorher ;) also auch nicht.

Dem Client ist es egal, ob der Server auf 32 oder 64 Bit läuft.

theorethisch vielleicht ;) praktisch funktioniert bei mir wie gesagt die Verbindung nur im 64-bit-odbc-programm und nicht im 32-bit-odbc-programm, bei den gleichen parametern ;)

[nobex]

M.E. liegt da etwas im 32 Bit-Pfad der Clientkomponenten quer.
Kannst Du testweise die ODBC-Treiber auf einem externen (reinen) 32-Bit-Client installieren und testen?

[Watson007]

ich habs!!!

als ich zufällig die tnsnames.ora in

C:\Oracle\admin\product\11.1.0\db_1\NETWORK\ADMIN

umbenannt hatte, ging die Verbindung auch im 64-Bit-ODBC-Programm nicht mehr, und zwar mit der selben Fehlermeldung wie sonst immer im 32-Bit-ODBC-Programm! Da dachte ich mir dann schon, das im 32-Bit-ODBC-Programm wahrscheinlich nur ein Problem mit der Namensauflösung bestand!

Damit die Verbindung auch im 32-Bit-ODBC-Programm geht, muss man auf die SQORA32.dll des 32-Bit-Oracle-Clients achten, und WO sie liegt! Denn diese DLL geht für die Suche nach der TNSNAMES.ORA einen Ordner in der Verzeichnishierarchie nach oben (vom eigenen Standpunkt aus gesehen), dann in das Unterverzeichnis NETWORK und da wiederum in das Unterverzeichnis ADMIN, dort muss dann die tnsnames.ora und die sqlnet.ora liegen.

Also kurz gesagt, in

C:\Oracle\admin\product\11.1.0

liegt bei mir db_1, das ist der Oracle-Server, und client_1, das ist der Oracle-Client. Im gleichen Verzeichnis (C:\Oracle\admin\product\11.1.0) musste ich also nur das Verzeichnis Network anlegen, darunter dann Admin, und in dem Verzeichnis dann die Kopien der tnsnames.ora ablegen...

>>Der Pfad zu der tnsnames.ora scheint in den 32-Bit-ODBC-Dlls hartgecodet zu sein, auch wenn mit relativen Verzeichnisangaben gearbeitet wird...<<
wie gesagt, das der Pfad zu den Oracle-Client-Komponenten in PATH vor den Oracle-Server-Komponenten liegt, reicht NICHT aus!

Es geht jetzt, sowohl im 32-Bit-ODBC-Programm als auch im 64-Bit-ODBC-Programm! endlich!

so, jetzt aber zum Sport!

>>Ergänzung:

das Verzeichnis Network gibt es ja, in C:\oracle\admin\product\11.1.0\client_1

Das Problem ist somit, das das Install-Programm diese DLLs nicht in das Unterverzeichnis BIN kopiert hat (wie bei den 64-Bit-ODBC-Komponenten), sondern eine Verzeichnisebene darüber. Oder anders herum, das der Pfad zu der tnsnames.ora in den DLLs hartgecodet ist, mit relativen Verzeichnisangaben.

[Watson007]

in der SQORA32.DLL wird daher sowas drinstehen wie

$Variable = '../Network/Admin/tnsnames.ora'

../ für ein Verzeichnis nach oben gehen, ./ wäre das aktuelle Verzeichnis

machen eigentlich schon alle Programme so, kann man daher Oracle nicht vorhalten. Ist einfach ein Fehler im Installer, der die DLLs in das falsche Verzeichnis ablegt.

Jedenfalls kann ich damit konstatieren, das diese DLLs die Parameter der tnsnames.ora nicht über irgendeine Schnittstelle abfragen, sondern die Textdatei schlicht selbst parsen. Irgendwie hätte ich gedacht, das bei Oracle etwas mehr "Mystik" dahinter steckt ;-) Na egal, ich wende schon wieder zuviel Zeit dafür auf....

[Watson007]

Nachtrag: jetzt musste ich den client auch auf meinem notebook installieren (win7 64).

Dabei habe ich noch herausgefunden, das die installation des "instantclients" (150 MB) nicht ausreicht für die 32-bit-odbc-verbindung, obwohl dann diese DLLs da sind - fehlten wohl noch Abhängigkeiten. Das 32-Bit-ODBC-Programm meldete dann jedenfalls, das die sqoras32.dll fehlte, obwohl sie korrekt in der Registry registriert war.

Mit der Administrator-Installationsoption gings dann (698 MB). Wobei er dann diese DLLs korrekt ins BIN-Verzeichnis gepackt hatte, aber vergessen hatte die tnsnames.ora vom server in das Network/admin-Verzeichnis des Clients zu kopieren. Als ich die Datei dahin kopiert hatte, gings dann im 32-Bit-ODBC-Programm. (Oracle Server und Client sind auf dem gleichen PC halt... konsequenter wärs wohl, die 64-bit-odbc-dlls nicht mit dem server installieren zu lassen, was er aber automatisch macht (64-bit-server). Oder wenn, dann auch gleich die 32-Bit-odbc-dlls mit).

Auf meinem Arbeits-PC hatte ich die Option "Laufzeit" (440 MB) gewählt, da scheint er die DLLs wie gesagt ins falsche Verzeichnis zu kopieren... und die tnsnames.ora zu kopieren vergisst er dann auch, aber finden würde er sie wie gesagt so eh nicht.

Na egal. Jedenfalls sollte damit alles klar sein.

Die Fehlermeldung "TNS: Kein Listener" ist jedenfalls falsch gewesen, er hatte schlicht die tnsnames.ora-Datei nicht gefunden....
Dran denken: auch wenn der Client auf dem gleichen Rechner wie der Server installiert ist, braucht er auf jeden Fall ne eigene tnsnames.ora-Datei zur Namensauflösung.