Umlaute beim Zugriff auf Oracle-Server (mit Access, ODBC)

[drnicolas]

Ich komme mit meinem Problem nicht weiter.

Ich habe eine auf Oracle basierende DB einer Praxis-verwaltung. Mit dem zugehörigen Clients werden natürlich die Umlaute korrekt dargestellt.

Nun verwende ich eigene Routinen für verschiedene Auswertungen aus Access heraus. Der zugriff erfolgt über Windows ODBC und funktioniert an sich.
Nur werden die umlaute falsch wiedergegeben.

Meine Experimente mit NLS_LANG als Umgebungsvariable haben immer nur Müll zutage gefördert.
Allerdings wehcselnden Müll, je nachdem ob ich mit WE8MSWIN2315, WE8ISO8859-P1/P15 oder WE8.PC850 probiere

Probiere ich auf demselben Rechner mit SQLplus - dann sind die Umlaute richtig; CHCP auf der DOS-Ebene gibt 850 zurück

Nun bin ich umso erstaunter, daß auch auf dem Rechner auf dem die (funktionierende) Cleint-Software läuft zum einen weder NLS_LANG definiert ist (trotzdem richtig)
und obendrein in SQLDEVELOPER wiederum fehlerhafte Umlaute kommen.

Ich verstehe es einfach nicht.

Hier kommen mal die Ausgaben der verschiedenen Parameter:

SELECT * FROM NLS_SESSION_PARAMETERS
NLS_LANGUAGE GERMAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE GERMAN
NLS_SORT GERMAN
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE


SELECT * FROM NLS_INSTANCE_PARAMETERS
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_SORT Null
NLS_DATE_LANGUAGE Null
NLS_DATE_FORMAT Null
NLS_CURRENCY Null
NLS_NUMERIC_CHARACTERS Null
NLS_ISO_CURRENCY Null
NLS_CALENDAR Null
NLS_TIME_FORMAT Null
NLS_TIMESTAMP_FORMAT Null
NLS_TIME_TZ_FORMAT Null
NLS_TIMESTAMP_TZ_FORMAT Null
NLS_DUAL_CURRENCY Null
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE


SELECT * FROM NLS_DATABASE_PARAMETERS
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8MSWIN1252
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 11.2.0.1.0


SELECT * FROM V$NLS_PARAMETERS
NLS_LANGUAGE GERMAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE GERMAN
NLS_CHARACTERSET WE8MSWIN1252
NLS_SORT GERMAN
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE

 

[drnicolas]

Ergänzung:
Ich habe jetzt auf dem Client-rechner noch mit NLS_LANG= GERMAN_GERMANY.UTF8 und ...UTF16 probiert.
Jeweils keine Besserung!
in der Registry sind aber nochmals NLS_LANG EInträge vorhanden.

 

[dabadepdu]

Jeweils keine Besserung! ...

Ich bin nicht mehr besonders im Oracle Thema, aber ein Grundproblem könnte sein, dass die Daten, die bereits vorhanden sind, durch den bestehenden Client falsch codiert in die DB geschrieben werden. Um das festzustellen, musst Du nicht mit dem neuen Client experimentieren, sondern feststellen, was genau der alte Client macht.
Es bringt Dir auch nichts, vergleiche mit anderen Clients zu machen, die wiederum unterschiedlich konfiguriert sein können verglichen mit Deiner Accessumgebung.
Alternativ kannst Du feststellen, ob der neue Client konsistent eingestellt ist. Also bekomme ich nach einer Dateneingabe mit dem neuen Client die Daten richtig ausgegeben (und werden sie dann im alten Client mglw. auch falsch angezeigt)
Das mal so als Ansatz, um das Problem einzukreisen.
Du müsstest klären, ob Du mit einer SingleByte DB oder Multibyte DB arbeitest. Einfach gesagt, würde ein SingleByte System die eingehenden Daten- egal wie sie codiert sind- immer in ein Byte reinquetschen und dabei dann u.U. Datenverlust erbringen. MultibyteSysteme haben dieses Problem weniger oder gar nicht.

 

[drnicolas]

Ich hole das Thema nochmal hoch weil immer noch ungelöst.

Ich kann mir schlecht vorstellen, dass die Daten falsch auf dem Server abgelegt sind. Wie gesagt, es ist eine 3rdparty-DB und das Clientprogramm auch. Ich weiss also letztlich nicht was die so machen.

Immerhin konnte ich auf dem Server wie auf einem Client-Rechner etwas weiterkommen:

Auf dem Server:
Mit sqlplus werden die Daten zunächst falsch ausgelesen.
Nach einem "chcp 437" kommen die Daten korrekt (mit den Umlauten)

Mit "chcp 850" kommen die Daten wieder falsch!

Auf einem Client kann ich dasselbe wiederholen. Insofern gehe ich davon aus, dass die Daten auf dem Server RICHTIG gespeichert sind.

AUf einem Linux-Client nutze ich oracledb unter Python. Das funktioniert prima, bis auf die Umlaute.

selbst wenn ich von meinem Client-Programm NLS_LANG auf "GERMAN_GERMANY.US8PC437 - und zwar vor dem Öffnen der Verbindung zum Server - dann kommen die Umlaute dennoch falsch.

Ich bin mit meinem Latein am Ende. Hat jemand eine Idee?