Eurozeichen per SQL

[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

[beegee]

@Fuerchau: kann man nicht direkt die CCSID im Serverjob ändern ?

[AS400.lehrling]

Was ist mit cp 1252

Gruß AS400.lehrling

[Fuerchau]

Wenn der Job bereits CCSID 1141 hat, kannst du da sowieso nichts verbessern.
Eine JOB-CCSID ist immer SBCS (1-Byte-Codepage).

Ggf. kannst du die Verbindungszeichenfolge noch anpassen: http://publib.boulder.ibm.com/infoce...c.htm&lang=_de

Allerdings kann ich da auch nichts finden.
Ich denke, das €-Symbol wurde im JDBC-Treiber einfach vergessen, da es beim ODBC-Treiber funktioniert.

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