Eurozeichen per SQL

[BenderD]

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

[beegee]

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

[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

[Fuerchau]

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.

[Fuerchau]

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

[beegee]

Cast hat leider nichts gebracht - kommt noch immer die Sonne statt Eurozeichen

SELECT BTSKTO, BTLFNR, BTFOLG, cast(bttext as vargraphic(75) ccsid 13488) as BTTEXT FROM STAMDATTST.BTGATP WHERE BTSKTO = '05100' AND BTLFNR = 5367 AND BTFOLG = 1 ORDER BY BTSKTO, BTLFNR, BTFOLG

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

[Pikachu]

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