-
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)
Zitat von Mark
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...9?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.
Zitat von Alram
-
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.
-
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
Zitat von 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
-
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
Similar Threads
-
By Azaron in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 05-12-06, 13:42
-
By alexander may in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 18-05-06, 20:16
-
By Der_Unwissende in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 14-11-05, 08:30
-
By bode in forum NEWSboard Java
Antworten: 7
Letzter Beitrag: 02-09-05, 15:09
-
By neuling_ in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 18-08-04, 12:11
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks