Eurozeichen per SQL

[Fuerchau]

CP 1252 ist die ANSI-Entsprechung von 273 EBCDIC und nur im IFS anwendbar.

[BenderD]

... mit CCSIDS widerspreche ich dir ungern, da kennst du dch eigentlich besser aus als ich --- aber:
das mit der Umsetzung im Serverjob hätte zur Folge, dass Information verloren geht, wenn in Tabellen mehrere CCSIDS vorkommen, da nämlich "fremde" Daten nicht ohne Verlust umgesetzt werden können.
Ich habe noch keinen JDBC Treiber von innen angesehen, weiß aber (mittlerweile) was so über die ARDPGM und DRDA Schnittstelle geht; da werden die Daten per SQLDA beschrieben (die die CCSIDs der Felder und Daten mit beschreibt) und die Daten werden binary geschickt.


Dieter

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.

[BenderD]

... mach mal einen DSPFFD, was da auf Feldebene steht.

Ich habe mir mal eine Tabelle mit einem 273 und einem 1141 Feld angelegt und da Euros reingeschrieben, Hex steht da immer die 9F drin, der Grüne zeigt das alles gnadenlos als Euro an, im JDBC kommt das 1141 Feld als Euro rüber, dass 273 als Rune oder Keilschrift. Welche CCSID der Job auch immer haben mag (auf Holgers Möhre darf ich mir das nicht angucken und meine schläft gerade), weiß ich nicht 1141 jedenfalls nicht...

D*B

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

[beegee]

Da steht 1141:

BTTEXT CHAR 75 75 14 Beides BTTEXT
Feldtext . . . . . . . . . . . . . . . : TEXTZEILE
ID des codierten Zeichensatzes . . . . . : 1141

[beegee]

Jetzt kenne ich mich nicht mehr aus: habe in der Datenbank in der DDS beim betreffenden Feld folgendes angegeben:

BTTEXT 75G TEXT('TEXTZEILE')
CCSID(13488)

Dann die Daten mit CPYF wieder reinkopiert, aber im Java kommt wieder die Sonne und nicht das Eurozeichen

[BenderD]

... was heißt denn hier im Java?

Jetzt kenne ich mich nicht mehr aus: habe in der Datenbank in der DDS beim betreffenden Feld folgendes angegeben:

BTTEXT 75G TEXT('TEXTZEILE')
CCSID(13488)

Dann die Daten mit CPYF wieder reinkopiert, aber im Java kommt wieder die Sonne und nicht das Eurozeichen

[beegee]

Warte, beim Kopieren habe ich eine Blödsinn gemacht.....

Java heisst, dass ich die Daten mittels JDBC in eine Java-Anwendung einlese und verarbeite...

[beegee]

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]

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

[beegee]

Entwicklung Java (6) mit Netbeans für Fat-Windows-Clients mit Datenbankzugriff auf die iSeries.

[Fuerchau]

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

[Fuerchau]

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.