View Full Version : Eurozeichen per SQL
Warte, beim Kopieren habe ich eine Blödsinn gemacht.....
Java heisst, dass ich die Daten mittels JDBC in eine Java-Anwendung einlese und verarbeite...
Also mit
BTTEXT 75G TEXT('TEXTZEILE')
CCSID(13488)
würde es zwar funktionieren, allerdings sind nach dem CPYF alle Eurozeichen nicht mehr in der Datei. Erst wenn ich welche in der Datenbank hinzufüge, habe ich diese dann auch nach dem SQL verfügbar.
Also für historischen Datenbestand eigentlich nicht brauchbar.
... davon sieht man noch nix, wo (auf welcher Büchse) und wie lässt du dir das anzeigen...
Warte, beim Kopieren habe ich eine Blödsinn gemacht.....
Java heisst, dass ich die Daten mittels JDBC in eine Java-Anwendung einlese und verarbeite...
Entwicklung Java (6) mit Netbeans für Fat-Windows-Clients mit Datenbankzugriff auf die iSeries.
@Dieter
Das ist ja genau das was auch passiert.
Wenn du in eine SBCS-CCSID Daten verschiederner Sprachen hineinschreibst, musst du schon selber wissen, wie die Daten wieder zu interpretieren sind (Stichwort 3-fach-cast).
SQL weiß das eben nicht und wandelt immer zwischen DB und Job ausser wenn einer von beiden *HEX ist.
Ein ODBC-Job ist niemals *HEX !
Bei SBCS hast du eben genau die erwarteten Darstellungsverluste (nicht zu verwechsalen mit Datenverlusten).
Ich nehme mal an (genau weiß das wohl nur die IBM), dass beim Kopieren von 1141 nach 13488 intern über 273 gewandelt wird.
Du kannst ggf. für die historischen Daten mittels
insert into neuedatei
select * from altedatei
und anschliessendem
update neuedatei
set feldxxx = replace(feldxxx, x'9F', '€')
(wenn x'9F' der €-Code ist)
die Daten reparieren.
Habe ich gemacht, leider werden aber trotzdem alle Eurozeichen nicht übernommen.
... Kopf schüttel ... zumindest für JDBC ist das klar Treibersache, was ja mein Test auch ausweist: 273 Feld ohne Euro, 1141 Feld mit Euro (der grüne macht das wieder anders, der liest transparent data und zeigt die so an, wie das Terminal (!!!) eingestellt ist. Dein Szenario gilt für den Transfer ins RPG.
@Dieter
Das ist ja genau das was auch passiert.
Wenn du in eine SBCS-CCSID Daten verschiederner Sprachen hineinschreibst, musst du schon selber wissen, wie die Daten wieder zu interpretieren sind (Stichwort 3-fach-cast).
SQL weiß das eben nicht und wandelt immer zwischen DB und Job ausser wenn einer von beiden *HEX ist.
Ein ODBC-Job ist niemals *HEX !
Bei SBCS hast du eben genau die erwarteten Darstellungsverluste (nicht zu verwechsalen mit Datenverlusten).
also, wenn ich eine weitere Tabelle deren Felder CCSID 13488 haben und meine Testtabelle mit CPYF *MAP *DROP reinkopiere, werden bei den 1141 er Feldern die Eurozeichen korrekt übernommen, bei den 273 Feldern, werden die Eurozeichen nicht übernommen (so wie das zu erwarten ist).
Das sieht mir alles so aus, als ob deine Felder in deiner ursprünglichen Tabelle krumm sind. Der Huddel liegt an der Datei und nicht am Java oder Treiber.
D*B
Also mit
BTTEXT 75G TEXT('TEXTZEILE')
CCSID(13488)
würde es zwar funktionieren, allerdings sind nach dem CPYF alle Eurozeichen nicht mehr in der Datei. Erst wenn ich welche in der Datenbank hinzufüge, habe ich diese dann auch nach dem SQL verfügbar.
Also für historischen Datenbestand eigentlich nicht brauchbar.
... ich habe den Dummfug gefunden:
deine Tabelle hatte die CCSID auf Dateiebene hängen, meine auf Feldebene. Im ersten Fall erfolgt die Umsetzung nach dem Job, im zweiten Fall wird es richtig gemacht!!!
Bei deinem CPYF hatte dein Job 273, also schmeißt es den Euro weg.
Du kannst also die Dateien mit 1141 (oder 13488) auf Feldebene anlegen, deinen Job auf 1141 stellen und kopieren.
Was auch gehen müsste, ist ein doppelter Cast erst auf 65535 und dann auf 1141.
Dieter