View Full Version : Eurozeichen per SQL
Tja, dachte ich auch - aber diese Jobs haben alle CCSID 1141 und trotzdem habe ich in meiner Java-Anwendung nur das Sonnensymbol und nicht das Eurozeichen.
Die Darstellung des Eurozeichens ist AS/400-spezifisch, in UNICODE (Java, Windows) belegt es eine andere Stelle und muss daher leider selber gemappt werden.
Korrekt funktionierts wahrscheinlich nur, wenn auch die AS/400-Datei in UCS2 (CCSID 13488) steht.
... trotzdem habe ich in meiner Java-Anwendung nur das Sonnensymbol und nicht das Eurozeichen.
Da muß noch irgendwo CCSID 273 sein, denn das Währungszeichen (Sonnensymbol) hat in CCSID 273 denselben Kodepunkt (9F) wie das Eurozeichen in CCSID 1141.
Selbst wenn ich die Toolbox JT400 nehme, muss ich mich um die Umsetzung kümmern, sprich mit einem replace ?
Übrigens, ein CHPF auf die CCSID 13488 wird mit Fehlermeldung
CPD322C abgebrochen (Ursachencode 5 - Die Daten sind für die angegebenen CCSID-Werte ungültig.)
@Pikachu: genau diesen Job suche ich, wo noch 273 drinnen steht.
... das hat mit der CCSID des Database Serverjobs nix zu tun. Die Daten haben in der Table (oder auf Feldebene) eine Codierung und der JDBC Treiber hat das nach UTF8 zu konvertieren. Wenn das nicht klappt, ist an der Table, oder dem Inhalt was faul, oder der Treiber hat einen Bug.
D*B
Selbst wenn ich die Toolbox JT400 nehme, muss ich mich um die Umsetzung kümmern, sprich mit einem replace ?
Übrigens, ein CHPF auf die CCSID 13488 wird mit Fehlermeldung
CPD322C abgebrochen (Ursachencode 5 - Die Daten sind für die angegebenen CCSID-Werte ungültig.)
@Pikachu: genau diesen Job suche ich, wo noch 273 drinnen steht.
... da sagt Fürchau aber genau das Gegenteil (19-04-07, 13:31 )
Deswegen bin ich auf den Serverjob gekommen.
... was da ODBC macht, habe ich nix zu gesagt. JDBC legt da fest, was rauskommen muss...
Was hat denn deine Tabelle, bzw. das Feld für eine CCSID - und was steht denn nun drin?
D*B
... da sagt Fürchau aber genau das Gegenteil (19-04-07, 13:31 )
Deswegen bin ich auf den Serverjob gekommen.
Das Problem ist, dass 1141 intern ja 273 ist und nur die 5250 das €-Symbol für diesen Codepunkt kennt.
Ich denke mit einem CAST auf UCS2 kannst du das ggf. erledigen (CHGPF geht da nicht):
cast(Feld as vargraphic(nn) ccsid 13488) as Feld
nn ist die definierte Länge.
Zuerst hatte diese 273, habs auf 1141 geändert - hatte aber keine Auswirkung.
Das steht drinnen - Klartext:
1 Digitalkamera Olympus C350 (3,2) € 26
Hex: 9F.....
F4C888A899898984D9A99AA4CFFF44F6F5444494FF
10497931321459106384742033500D3B2D0000F026
@Dieter
Leider ist die CCSID des Server-Jobs sehr wichtig!
Diese wird aus der Sprache des Users bzw. aus demn Systemwert QCCSID entwickelt.
Ist QCCSID = 65535, nimmt der Serverjo 037 an.
Dies ist deshalb nötig, da ja auch der Serverjob die Daten beim Lesen in die Job-CCSID konvertiert (ausser bei 65535) bevor diese dann per ODBC verschickt werden.
Der ODBC/JDBC-Treiber wandelt diese dann in seinen entsprechenden Code um (UTF8, Unicode, ANSI, ASCII).
Für den AS/400-ODBC/JDBC gibts dann halt noch die Einstellung für die HEX-Umsetzung von CCSID 65535:
a) Job-CCSID wenn <> 65535
b) 037 wenn = 65535
Wobei dann allerdings tatsächliche Hexwerte (also echte Binärfelder) nicht verarbeitet werden können.