lokaler Java DB2 Zugriff schlägt nach Releasewechsel fehl

[Fuerchau]

Wenn ich bei CLI Zielfelder als GRAPHIC(13488) angebe, ist die CCSID des Jobs tatsächlich egal (was anderes als Embed-SQL oder CLI gibts sowieso nicht auf der AS).
Der Toolbox-Treiber weiss das, der Native-Treiber verwendet dann wohl CHAR und das ist immer Job-CCSID was für Mehrsprachigkeit bzw. Unicode in der DB tödlich ist.

[Sven Schneider]

Missverständnis.
Es geht nicht um die CCSID der Tabelle oder der Felder sondern um die CCSID des SQL-Statements, welches an die CLI-API ubergeben wird.
Hier wird von Unicode nach EBCDIC gewandelt und hier ist eine definierte CCSID notwendig.
Sonst kommt z.B. statt :

select * from tabelle where feld like 'xxx%'
eben
select * from tabelle where feld like 'xxx§'

oder irgend etwas ähnlich falsches an der CLI-Schnittstelle an.

Sven

[BenderD]

Einspruch, jeder RPG Schinken kann das ohne dass der Job eine CCSID braucht. Was besonders ärgerlich an der Angelegenheit ist: zunehmend muss man damit rechnen, dass nach Release Wechseln Programme nicht mehr funktionieren, oder gar nicht mehr kompilierbar sind. Quo vadis as400???

Dieter Bender

Missverständnis.
Es geht nicht um die CCSID der Tabelle oder der Felder sondern um die CCSID des SQL-Statements, welches an die CLI-API ubergeben wird.
Hier wird von Unicode nach EBCDIC gewandelt und hier ist eine definierte CCSID notwendig.
Sonst kommt z.B. statt :

select * from tabelle where feld like 'xxx%'
eben
select * from tabelle where feld like 'xxx§'

oder irgend etwas ähnlich falsches an der CLI-Schnittstelle an.

Sven

[Sven Schneider]

Hallo Dieter,
das stimmt nicht ganz.
Die Job CCSID (z.B. mit CHGJOB CCSID(65535)) kann durchaus 65536 sein, aber :

Ist die ID des codierten Zeichensatzes (CCSID) des Jobs
nicht 65535, stimmt die Standard-ID des codierten
Zeichensatzes mit der ID des codierten Zeichensatzes des
Jobs überein. Ist die ID des codierten Zeichensatzes des
Jobs 65535, wird aufgrund der Sprachen-ID des Jobs
(LANGID) ein entsprechender Wert für die Standard-ID des
codierten Zeichensatzes festgelegt.

(Aus Online-Hilfe WRKJOB)

Die "Standard-ID des codierten Zeichensatzes" ist immer ein definierter Wert, ggf. über Sysval QLANGID zugeordnet, und niemals 65535.
So das der Job immer eine definierte CCSID hat.
Warum der JDBC-Native-Treiber dies nicht verwendet, erschliesst sich mir nicht.

Bei vorumgewandelten Programmen mit embedded SQL oder CLI sieht das ganze wieder anders aus. Hier wird bereits zur Compile-Zeit die korrekte CCSID für die SQL-Anweisungen bzw. verwendeten Strings zugeordnet, so das die CCSID des Jobs zu Laufzeit egal ist.



Sven