ORA: N-Datatypes und Treiberproblem
Martin Meyer
in einer ORA 9.2.0.1 DB habe ich eine Tabelle u.a. mit einer NVarchar2-
und einer NClob-Spalte. Wenn ich schreibend mit (ADO) OraOleDB-Provider
(9.2.0.4) auf das NVarcha2-Feld zugreife, werden etwaige
"Unicode"-Zeichen nicht korrekt geschrieben.
Komischerweise funktioniert das auf die gleiche Tour mit dem NClob-Feld
tadellos.
Versuche ich es über ODBC (auch ADO, OleDB über ODBC-Provider) mit
dem ORA-ODBC-Teiber, funktioniert das Update bei beiden N-Typen korrekt.
Ebenso natürlich, wenn ich die Tabelle über den ODBC-Treiber in Access
einbinde (DAO).
Versuche ich die Updates mit dem SQLPlus-Worksheet werden die Zeichen
sowohl im NVarchar- als auch im NClob-Feld falsch geschrieben.
(Worüber greift SQL-Worksheet eigentlich auf die DB zu - JDBC?)
Entweder hat der Oracle-OleDB-Treiber eine Macke (aber funktioniert er
dann mit dem NClob?) oder es ist vielleicht etwas mit meinen
Zeichensatzeinstellungen nicht korrekt.
Client und DB sind zZ auf dem gleichen (Win)-System installiert, von
daher sollten die default-NLS-Einstellungen eigentlich harmonieren.
Als NLS_NCHAR_CHARACTERSET ist AL16UTF16 eingestellt, was soweit ok sein
sollte, sonst würde es über ODBC ja auch nicht gehen(?).
Kann es sein, dass die unterschiedlichen Treiber (OleDB, ODBC) die
Client-Zeichensatzeinstellung unterschiedlich auswerten?
Ziel ist es, einen brauchbaren OleDB-Treiber (oder funktionierende
Einstellungen) zu finden, weil der ganze Rest der Anwendung diesen
Treiber bisher erfolgreich auf den Ora-OleDB-Treiber aufsetzt.
Und statt der NVarchar-Spalte einen NClob einzusetzen, wäre mit Spatzen
auf Kanonen geschossen.
Hat jemand eine Idee, was man versuchen könnte, um den Treiber
NVarchar-tauglich hin zu bekommen?
TIA & Gruß,
Martin
--
Bei Antworten per eMail bitte an die Reply-To Adresse senden.
Oder der From-Adresse den String "nospam_" voranstellen.
eMails an die unmodifizierte From-Adresse werden ungelesen geloescht.
Bernd Eckenfels
> Hat jemand eine Idee, was man versuchen könnte, um den Treiber
> NVarchar-tauglich hin zu bekommen?
Der Treiber konvertiert die Zeichen, und auf Client Seite muss er dazu
wissen in welchem Zeichensatz die Zeichen vorliegen. Ich weiss nicht genau
wie das bei den ADO/OLD Treibern ist.
Aber angeblich wird es bei OCI mit OCIEnvNlsCreate gesetzt. Wenn man da
nichts angibt kann man NLS_LANG environemnt Variable nehmen.
Gruss
Bernd
Martin Meyer
vielen Dank für Deine Hinweise.
Bin leider auch nach Stöbern in den Oracle-Dokus der Lösung nicht
nähergekommen.
Angeblich würde bei Oledb automatisch in den "Unicode-Modus"
geschaltet, wenn der Client-Zeichensatz kein Unterzeichensatz (subset)
des DB-Zeichensatzes ist ???
Weder funktioniert der Treiber, noch das SQL-Worksheet korrekt,
wenn ich NLS_LANG mal auf Einstellungen setze in denen ich die
verwendeten Test-Sonderzeichen vermute. Ich halte es aber auch für keine
echte Lösung, an NLS_LANG rumzustellen, weil die mit
GERMAN_GERMANY.WE8MSWIN1252 verbundenen
Einstellungen schon sinnig für die Verwendung in unseren Breitengraden
sind.
Ich frag mich wofür es die NDatentypen gibt, wenn ich doch nur bestimmte,
meiner Einstellung entsprechende Zeichen darin speichern kann.
Mal ADO und oledb außenvorgelassen. Was muss ich tun, damit wenigstens
Oracles sqlplus-Worksheet selber mit dem Schreiben klar kommt?
Lesen tut's ja offenbar korrekt, wenn ich die Sonderzeichen über Access
(ODBC) in die Ora-Tabelle schreibe.
Also ehrlich - so ein Krampf wie hier bei Oracle habe ich bei anderen
DBMS's noch nicht gesehen: da nimmt man die passenden Datentypen und gut
ist's :(
Bernd Eckenfels
> Ich frag mich wofür es die NDatentypen gibt, wenn ich doch nur bestimmte,
> meiner Einstellung entsprechende Zeichen darin speichern kann.
Du kannst alle drin speichern, es geht darum in welchem Zeichensatz du diese
an den Treiber übergibst, und das musst du mit der Environmentvariable
bestimmen, wenn du es nicht in OciCreateEnv uebergibst.
Gruss
Bernd
Martin Meyer
On Fri, 21 Mar 2008 16:22:18 +0000 (UTC), Bernd Eckenfels
<ec...@lina.inka.de> wrote:
> [...]
>Du kannst alle drin speichern, es geht darum in welchem Zeichensatz du diese
>an den Treiber übergibst, und das musst du mit der Environmentvariable
>bestimmen, wenn du es nicht in OciCreateEnv uebergibst.
Vielleicht reden wie anander vorbei, was dann aber wahrscheinlich an mir
liegt. <:-|
Also konkret die Frage: Was muss ich dann, damit ich mit dem
SQL-Worksheet -sagen wir einmal- kyrillische, hebräische und kansi
Zeichen gemischt in die NVarchar-Feldern schreiben kann und sie
anschließend wieder korrekt vom Worksheet angezeigt bekomme?
Das Anzeigen mit dem Worksheet funktioniert bereits jetzt, wenn ich die
Zeichen zB. über Access/ODBC in die N-Spalten bringe.
Datenbankeinstellungen:
NLS_CHARACTERSET WE8MSWIN1252
NLS_NCHAR_CHARACTERSET AL16UTF16
Client (Win2000):
NLS_LANG GERMAN_GERMANY.WE8MSWIN1252
Das Ändern des NLS_CHARACTERSET auf einen UTF-Zeichensatz
kann ja wohl nicht *wirklich* eine Lösung sein, da dies nur umständlich
möglich ist und ich mich zudem frage, wozu dann die NChar-Typen
gut sein sollten?
TIA & Gruß,
Bernd Eckenfels
> Also konkret die Frage: Was muss ich dann, damit ich mit dem
> SQL-Worksheet -sagen wir einmal- kyrillische, hebräische und kansi
> Zeichen gemischt in die NVarchar-Feldern schreiben
> Client (Win2000):
> NLS_LANG GERMAN_GERMANY.WE8MSWIN1252
Da du keine kyrillischen und hebräischen Zeichen in Win1252 speichern
kannst, kannst du sie auch nicht als Win1252 an den OCI Treiber übergeben.
Ich vermute mal als URF8 würde es gehen.
> Das Ändern des NLS_CHARACTERSET auf einen UTF-Zeichensatz
> kann ja wohl nicht *wirklich* eine Lösung sein, da dies nur umständlich
> möglich ist und ich mich zudem frage, wozu dann die NChar-Typen
> gut sein sollten?
Wenn man die Variable nicht benutzen will, dann muss man das in der API
anders nutzen, da kann ich dir aber nicht sagen wie, weil ich nur Java
verwende und dort tut es einfach.
Gruss
Bernd