Konvertierungsfehlr beim Speichern von Unicode

[jobo]

Hallo,

ich habe ein Problem mit dem Speichern von Unicode in Oracle. Kann nicht mal sagen, wo überhaupt der Fehler liegen könnte. Delphi, ADO, Oracle Client ..?
Problem:
Wenn ich Unicode speichere, werden die Zeichen (z.B. Japanische Buchstaben) als umgekehrte Fragezeichen dargestellt (nach dem refresh des grids). Daten, die ich mit 3. Anwendungen eintrage, werden aber sauber angezeigt.

Details:
Das betroffene Feld ist vom Datentyp NVarChar, der Zeichensatz dazu AL16UTF16. Die Delphi-Anwendung ist ohne Programmcode aus TADOConnection, TADODataSet, TDataSource, TDBGrid, TDBNavigator zusammengeklickt. (Delphi 2010)

Effekte:
Ich habe mittlerweile eine 2. DB eingerichtet, die auf AL32UTF8 eingerichtet ist. Hier funktioniert das gleiche Testprogramm problemlos. D.h. Unicode zeichen werden sauber dargestellt und lassen sich auch einfügen und ändern. Das ist zwar erfreulich, dürfte NVarchar Spalten aber gar nicht jucken, wenn ich da richtig liege. :stupid:

Wo und wie macht Delphi/Ado da die Unterscheidung? Ich hab alle NLS Einstellungen verglichen und mittlerweile auch die ADOConnection Properties, ich finde keine Unterschiede.

Weiß jemand Rat?
Danke, Jo

[Bernhard Geyer]

Welcher ADO-Provider? Falls er von MS ist - Dieser ist Schrott ist wird mittlerweile von M$ auch als nicht mehr unterstützt/eingestampft bezeihchnet.

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1064840)

Welcher ADO-Provider? Falls er von MS ist - Dieser ist Schrott ist wird mittlerweile von M$ auch als nicht mehr unterstützt/eingestampft bezeihchnet.

Oh das geht ja schnell! :)

Der vom 11er Oracle Client. AdoConnectionsProperties :
Provider Friendly Name: Oracle Provider for OLE DB
Provider Name: OraOLEDB11.dll
Provider Version: 11.2.0.1.0

[jobo]

Ich habe der gleichen Testanwendung noch eine Verbindung zu Access MDB (via JetEngine) gespendet. Hier zeigen sich auch keine Auffälligkeiten. Also Anzeige und Insert, Update von Japanisch oder Russisch bspw. funktioniert.

Wer es nachvollziehen möchte:
Beim Zusammenklicken der Komponenten muss man lediglich darauf achten, einen brauchbaren Font im DBGrid zu wählen, z.B. @Arial Unicode MS.

[jobo]

So, nachdem ich ACCESS für Testdaten verwendet habe, hab ich es nun zur Testeingabe verwendet.
Wenn ich per ODBC Verknüpfung auf die Oracle Daten zugreife (gleicher Oracle Client wie beim OLEDBProvider), funktionieren beide DB wie definiert/gewünscht.

Aus Spaß oder Verzweifelung :roll: hab ich dann wieder das Delphi Testprogramm genommen und die ADOConnection um JET OLE DB Provider auf die zuvor definierten Oracle ODBC Datasource gesetzt. Von hinten durch die Brust ins Auge, aber zu meiner Überraschung funktioniert auch hier der Zugriff problemlos.

Sieht so aus, als ob der Oracle OLE DB Provider für die Tonne ist.

Delphi-Quellcode:

Provider=OraOLEDB.Oracle.1;Data Source=devstd; ..   >> geht nicht
Provider=OraOLEDB.Oracle.1;Data Source=devAL32; ..   >> geht 
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\db1.mdb; ..   >> geht 
Provider=MSDASQL;Data Source=DEVSTD;Extended Properties="DSN=DEVSTD;DBQ=devLTEstd ;.."    >> geht !!

[jobo]

Hallo,

das "Problem" liegt bei den Provider-Einstellungen des Oracle OLE DB Treibers. Es ist also kein Delphi Problem, sondern besteht immer bei Verwendung dieses Treibers.

Wenn in der Oracle Datenbank NVarChar Felder geändert werden, muss die Operation entweder über die ADOConnection oder über das Command Objekt mit der Property

Code:

NDataType=True

erfolgen. Dann werden MultiByte Zeichen bei Insert/Update nicht zerstört.