View Full Version : Eurozeichen per SQL
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
@Fuerchau: kann man nicht direkt die CCSID im Serverjob ändern ?
AS400.lehrling
03-11-10, 13:08
Was ist mit cp 1252 :)
Gruß AS400.lehrling
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/infocenter/iseries/v5r4/index.jsp?topic=/rzahh/jdbc.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.
CP 1252 ist die ANSI-Entsprechung von 273 EBCDIC und nur im IFS anwendbar.
... 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.
... 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
Da steht 1141:
BTTEXT CHAR 75 75 14 Beides BTTEXT
Feldtext . . . . . . . . . . . . . . . : TEXTZEILE
ID des codierten Zeichensatzes . . . . . : 1141
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
... 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