bestimmte Sonderzeichen finden

[defo]

Dann würde ich mal die Textdateien unter die Lupe nehmen und deren Codierung prüfen.
Vermutung, OEM codierte Dateien werden bei Euch falsch dargestellt. Vielleicht kannst Du das prüfen.

[Wernfried]

Schau mal mit DUMP nach was tatsächlich (auf Bit Level) in der DB drin steht.

Welche DB Version (Client & Server) verwendet ihr? Normalerweise muss man sich um die Konvertierungen keine Gedanken machen, das macht der Oracle Treiber alles automatisch. Ich meine mich aber zu erinnern, dass es bei früheren Versionen (Oracel 9 oder 10) Probleme damit gab.

Ein dankbares Zeichen zum testen ist übrigens das Euro-Zeichen. Es befindet sich auf der Tastatur und wird binär fast überall anders dargestellt:

CP850 und CP437 (OEM): Nicht vorhanden
ISO-8859-1: nicht vorhanden
ISO-8859-15: 0xA4
CP1252 (auch ANSI genannt): 0x80
UTF-8: 0xE2 82 AC
UTF-16: 0x20 AC

Gruss

[Martin R.]

Hallo Euch beiden,

wir nutzen 11.2.0.2.0

Und es ist wirklich so, dass statt des € ein ? angezeigt wird.
Mit der Textdatei muss ich mal sehen, ob ich da eine Chance habe.

Vielen DAnk Euch beiden

Gruß

Martin

[Martin R.]

Und als Nachtrag

dump(NAME, 10, 1, 20),NAME ergibt Typ=1 Len=5: 191,110,105,111,108 ¿niol

Der Name lautet richtig Âniol.

Wobei ich die 191 hier http://docs.oracle.com/cd/B28359_01/...002.htm#i55214 oder hier http://publib.boulder.ibm.com/infoce...sciit.htmnicht gefunden habe

Gruß

Martin

[Wernfried]

191 dezimal ist hexadezimal 0xBF. Im ISO-8859-15 Zeichensatz (der Zeichensatz der DB) ist dort das auf dem Kopf stehende Fragezeiche, siehe http://de.wikipedia.org/wiki/ISO_8859-15

Wenn deine Konsole ¿niol anzeigt ist es genau das was in der DB drin steht.
Es würde mich sehr wundern wenn irgendein Client diesen Namen korrekt als Âniol zeigen würde, denn das steht in der DB nicht drin - zumindest habe ich auf die Schnelle keinen Zeichensatz gefunden, der am Codepoint 0xBF das Zeichen "Â" definiert hätte.

Das Problem liegt also eher bei der Eingabe der Daten. Da musst du dir wohl die Text Datei genauer ansehen.

Gruss

[Martin R.]

Hallo Wernfried,

danke Dir.
Werde mal mit unserer DAtenanahme und/oder dem Lieferanten sprechen.

Ich habe jetzt mal einen(für mich) ineterssanten Test gemacht.

Ich habe eine kleine Tabelle im Developer erstellt
select * from test_zeichen;

1 €
2 Ó
3 Â


select * from test_zeichen;

ID ZEICHEN
------ ----------
1 Ç
2 Ë
3 ┬


Im Developer werden sie richtig angezeigt, geh ich auf die Konsole, so wie oben dargestellt.
Mit dem Client kannst Du recht haben, da ist es so eine Sache, teile der angezeigten Daten kommen aus einer Oracle-DB, von einem System auf dem Host oder SAP.

Seltsam nur, das Daten, die aus unserer DB kommen, von einem mvs-job abgeholt werden, dann vom host gespoolt werden wieder 'richtig' sind. Und diese Daten stammen definitiv aus unseren DBn.

Viele Grüße
und danke nochmals!

Martin

[Uschi Blanz]

hallo,

wenn sqlplus über ein DOS-fenster aufgerufen hat, hat man den DOS(IBM)-Zeichensatz. Wenn man direkt tippt (auch copy,paste) werden die Umlaute falsch. "richtige" Umlaute entsprechend falsch angezeigt.
Für die korrekte Anzeige hilft bloß ein Tool, das den passenden Zeichensatz (in dem Fall ansi) kann. Für insert/update helfe ich mir immer so:
insert bzw update im Editor tippen , da sind die richtigen Umlaute - abspeichernn als irgendwas.sql und im sqlplus-DOS-Fenster einfach das skript ausführen

Gruß
uschi

[Martin R.]

Hallo Uschi,

vielen Dank!

Leider habe ich keinen Einfluss auf den Import der Daten.

Viele Grüße

Martin

hallo,

wenn sqlplus über ein DOS-fenster aufgerufen hat, hat man den DOS(IBM)-Zeichensatz. Wenn man direkt tippt (auch copy,paste) werden die Umlaute falsch. "richtige" Umlaute entsprechend falsch angezeigt.
Für die korrekte Anzeige hilft bloß ein Tool, das den passenden Zeichensatz (in dem Fall ansi) kann. Für insert/update helfe ich mir immer so:
insert bzw update im Editor tippen , da sind die richtigen Umlaute - abspeichernn als irgendwas.sql und im sqlplus-DOS-Fenster einfach das skript ausführen

Gruß
uschi

[Martin R.]

Hallo nochmals,

in der Eingabedatei wird als Zeichensatz ISO-8859-1 verwendet.
Dies als Nachtrag. Was natürlich immernoch keine Lösung darstellt;-)

Viele Grüße

Martin