View Full Version : lokaler Java DB2 Zugriff schlägt nach Releasewechsel fehl
Hi,
Nachdem wir ein Update von V5R1 auf V5R3 bekommen haben inklusive Update von Java 1.2 auf Java 1.4.2 läuft ein Java-Programm auf der iSeries nicht mehr, dass auf eine DB2 Datenbank zugreifen soll. Statt der Verbindung bekomme ich eine SQLException:
INTERNAL ERROR: Creation of DB2Driver object for registering with DriverManager failed.
// database connection
try {
Class.forName(cDBDriver);
conn = DriverManager.getConnection(cConnectURL);
} catch (Exception e) {
logger.error(e.toString());
}
cDBDriver hat den Wert "com.ibm.db2.jdbc.app.DB2Driver"
cConnectURL hat den Wert "jdbc:db2://*local"
Der Code wurde auf einem Windows PC (Windows 2000 Prof.) mit dem SDK 1.4.2_02 geschrieben und die fertigen Klassen wurden dann auf der iSeries abgelegt. Hat bis vor dem Releasewechsel wunderbar funktioniert.
Woran könnte es liegen, dass das Programm jetzt nicht mehr funktioniert sondern diesen Fehler bringt?
Bin für jede Hilfe dankbar,
Mark
Hallo,
da haben sich ein paar Jungs bei IBM hingesetzt und sich intensiv garnix gedacht. Seit V5R3 kann man den native Treiber nicht mehr verwenden, wenn der Job die CCSID 65535 hat, (was ja meistens der Fall ist).
Änderung im OS400 mit chgjob, oder beim SBMJOB angeben, oder ä.
PS: ich übernehme keine Garantie dafür, was sonst noch so alles passiert, wenn man die CCSID des Jobs ändert (ich habe diesen Quatsch nicht erfunden). Im Java selber dürfte das keine Auswirkungen haben (hoffe ich zumindest).
mfg
Dieter Bender
PS: oder den Toolbox Treiber verwenden, der geht immer noch und hat IMHO weniger Bugs (wobei obiges ein Feature ist)
Hi,
Nachdem wir ein Update von V5R1 auf V5R3 bekommen haben inklusive Update von Java 1.2 auf Java 1.4.2 läuft ein Java-Programm auf der iSeries nicht mehr, dass auf eine DB2 Datenbank zugreifen soll. Statt der Verbindung bekomme ich eine SQLException:
INTERNAL ERROR: Creation of DB2Driver object for registering with DriverManager failed.
// database connection
try {
Class.forName(cDBDriver);
conn = DriverManager.getConnection(cConnectURL);
} catch (Exception e) {
logger.error(e.toString());
}
cDBDriver hat den Wert "com.ibm.db2.jdbc.app.DB2Driver"
cConnectURL hat den Wert "jdbc:db2://*local"
Der Code wurde auf einem Windows PC (Windows 2000 Prof.) mit dem SDK 1.4.2_02 geschrieben und die fertigen Klassen wurden dann auf der iSeries abgelegt. Hat bis vor dem Releasewechsel wunderbar funktioniert.
Woran könnte es liegen, dass das Programm jetzt nicht mehr funktioniert sondern diesen Fehler bringt?
Bin für jede Hilfe dankbar,
Mark
Hi,
Danke für die Info mit der CCSID, das war tatsächlich die Lösung!!
Gruß,
Mark
hallo,
eine erläuterung von der IBM gibts unter:
http://www-912.ibm.com/s_dir/slkbase.NSF/0/9ea41ee0c6099d1e86256caa006e4b59?OpenDocument
vielleicht wirds dann verständlicher.
lg alram
Hallo,
da wird garnichts klarer:
- Java verwendet UniCode
- jede Table kennt ihr Characterset
- die JDBC Spezifikation legt fest, dass nach Unicode konvertiert wird
da ist für den Treiber kein Spielraum und da braucht er auch keine CCSID in seinem AS400 Job und der Toolbox Treiber hat noch nie eine CCSID benötigt und Datensalat habe ich da auch noch keinen gesehen.
mfg
Dieter Bender
PS: Ausreden werden nicht besser oder glaubwürdiger, wenn sie von IBM kommen.
hallo,
eine erläuterung von der IBM gibts unter:
http://www-912.ibm.com/s_dir/slkbase.NSF/0/9ea41ee0c6099d1e86256caa006e4b59?OpenDocument
vielleicht wirds dann verständlicher.
lg alram
Sven Schneider
12-07-05, 19:43
Hallo Dieter,
das hat nichts mit den JDBC-Spezifikationen zu tun.
Der Native JDBC Treiber nutzt intern, wie du sicherlich weist, die CLI-Schnittstelle und die bekommt ihre Daten (SQL Anweisungen) in EBCDIC-Codierung.
Daher muss diese die CCSID schon wissen, insbesondere dann wenn in der SQL-Anweisung invariante Zeichen, wie %, verwendet werden.
Für den Toolbox-Treiber ist das irrelevant, da dieser direkt Unicode verarbeitet und wahrscheinlich auch intern an den Database HostServer weitergibt.
Sven
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
12-07-05, 21:59
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
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
14-07-05, 16:35
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