Eurozeichen per SQL

[beegee]

Habe ich gemacht, leider werden aber trotzdem alle Eurozeichen nicht übernommen.

[BenderD]

... 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).

[BenderD]

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.

[BenderD]

... 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

[beegee]

Das Kopieren hat jetzt funktioniert.
Die Job-CCSID ist eh auf 1141, allerdings war die zu kopierende Datei auf 273. Nach Umstellung auf 1141 hat dann das CPYF die Eurozeichen mitkonvertiert.

Damit geht alles - VIELEN DANK !!

Allerdings bedingt dies, dass man solche Felder, wo Eurozeichen vorkommen können, auf Graphikfelder umstellen muss. Noch dazu muss ich testen, wie die bestehenden laufenden RPG-Programme mit dem neuen Dateifeld zurechtkommen.

Wie meinst du das mit dem Cast?
Ginge dies auch mit normalen 1141-Feldern oder bleibt mir eine Umstellung auf Graphikfelder mit 13488 nicht erspart ?

[BenderD]

... keineswegs, 1141 auf Feldebene, ohne jede weitere Maßnahme geht ebenfalls!!!
Den Unterschied etc. kannst du testen mit:
CREATE TABLE TESTEURO2(F273 char(5 ) ccsid 273
NOT NULL WITH DEFAULT, F1141
char (5 ) ccsid 1141 not null with default)

mit cast meine ich:

select cast( cast (f273 as char(5) CCSID 65535)
as char(5) ccsid 1141)

bzw.:
select cast(cast( cast (f273 as char(5) CCSID 65535)
as char(5) ccsid 1141)
as graphic(10) ccsid 13488)

mit letzterem Verfahren (cast nach 65535 und anschließend in das, was man haben will). das man auch in eine View einbauen kann, geht ziemlich viel.

D*B

Allerdings bedingt dies, dass man solche Felder, wo Eurozeichen vorkommen können, auf Graphikfelder umstellen muss. Noch dazu muss ich testen, wie die bestehenden laufenden RPG-Programme mit dem neuen Dateifeld zurechtkommen.

Wie meinst du das mit dem Cast?
Ginge dies auch mit normalen 1141-Feldern oder bleibt mir eine Umstellung auf Graphikfelder mit 13488 nicht erspart ?

[Fuerchau]

Genau das bekannte Problem, wenn unterschiedliche CCSID's im Spiel sind.

Wenn deine Datei mit €-Zeichen auf CCSID 1141 steht, kannst du diese auch per JDBC abfragen. Ein Umkopieren ist da nicht erforderlich (siehe Dieters Beispiel).

Die laufende Anwendung hat damit kein Problem, da ja 1141 zu 273 bis auf das €-Zeichen kompatibel ist.
Letztlich ist es (fast) egal welche CCSID die PF/TABLE hat, so lange man in sich konsistent ist.

Siehe hierzu auch meinen COMMON-Beitrag zum Thema CCSID.

[Fuerchau]

Die Umstellung auf Grafik-Felder (UCS2) würde ich für die laufende Anwendung nicht durchführen, da dies nur auber von ILERPG und SQL unterstützt wird.
Spätestens bei DSPF/PRTF hört das nämlich per default auf, hier muss man massiv in die Anwendung eingreifen.

Mit der CCSID 1141 auf Datei/Job/5250/QCCSID-Ebene bist du aber konsistent bis hin zu ODBC/JDBC.