SQL0901-Fehler

[KM]

Hallo,

wir haben ein Java-Programm im Einsatz, das bereits seit Jahren problemlos läuft und per SQL diverse Daten von der AS/400 ermittelt. Die Hintergründe tun hier nichts zur Sache.
Seit einer Woche erhalte ich seltsamerweise folgende Fehlermeldung:

Fehler: [SQL0901] SQL-Systemfehler.                                             
java.sql.SQLException: [SQL0901] SQL-Systemfehler.                              
 at com.ibm.as400.access.JDError.throwSQLException(JDError.java:703)            
 at com.ibm.as400.access.JDError.throwSQLException(JDError.java:669)            
 at com.ibm.as400.access.AS400JDBCStatement.commonExecute(AS400JDBCStatement.jav
a:963)                                                                          
 at com.ibm.as400.access.AS400JDBCStatement.executeQuery(AS400JDBCStatement.java
:2275)

Das scheint ein sehr allgemeiner SQL-Fehler zu sein und ich kann daraus leider nix rauslesen. Außerdem werden viele Server-Dumps (QPSRVDMP) in der OUTQ QEZDEBUG erstellt, die aber auch in erster Linie nur kryptische Zeichen enthalten.

Nachdem weder an der Systemumgebung, noch am Programm irgendetwas geändert wurde, würde ich jetzt mal vermuten, dass das SQL-Package QZDAPKG einen Schuss hat. Soll ich das mal löschen und neu erstellen lassen? Oder habt Ihr andere Tipps?

Vielen Dank,
KM

[B.Hauser]

Das Erstellen des Packages ist zumindest ein guter Ansatz.

Ansonsten ist SQL0901 ein Systemfehler, den an die IBM gemeldet werden sollte. Die System-Dumps sind für die Analyse durch IBM hilfreich.

Birgitta

[KM]

ok, dann werde ich das SQL-Package mal löschen und neu erstellen lassen. Mal sehen wie es danach aussieht.

Vielen Dank,
KM

[Fuerchau]

Ggf. wäre das SQL schon interessant ob überhaupt Schemaabfragen verwendet werden müssen die vom QZDAPKG gespeichert sind.
Es kann auch das, ggf. autmatisierte, SQLPKG der Anwendung sein (meist in QGPL). Dieses kann ebenso einfach gelöscht werden.

[BenderD]

... package Verwendung wird mit Treiber Properties gesteuert - und am besten schaltet man das ab. Der sogenannte extended dynamic package support hilft wenig und schadet manchmal massiv.

D*B

[KM]

package Verwendung wird mit Treiber Properties gesteuert - und am besten schaltet man das ab. Der sogenannte extended dynamic package support hilft wenig und schadet manchmal massiv.

Das verwenden wir in unserem Fall gar nicht.

[Fuerchau]

Das ist en Problem denn der Default ist eben "mit SQLPKG", man muss es leider explizit ausschalten.

[KM]

der Default ist eben "mit SQLPKG", man muss es leider explizit ausschalten.

Wo steht das? Der Default ist "false". Siehe hier

http://publib.boulder.ibm.com/infoce...roperties.html

[Fuerchau]

OK, Danke.
JDBC arbeitet da wohl "vernünftiger" als ODBC, da ist der Default true.

Ist das Zielsystem ggf. V7?

Ich habe da auch sporadisch Probleme mit "select * "-Abfragen.
Neben Querytimeout auf leeren Dateien auch andere Fehler, meist "invalid columninfo".

Abfragen mit Feldnamen funktionieren grundsätzlich.

[BenderD]

Das verwenden wir in unserem Fall gar nicht.

... dann bringt das löschen auch nix!

D*B

[KM]

... dann bringt das löschen auch nix!

stimmt, das hab ich jetzt auch festgestellt. Ich hab die SQL-Packages alle gelöscht und hab immernoch dasselbe Problem.

Jetzt ist mir aufgefallen, dass dieser SQL0901-Fehler nur bei einem bestimmten SQL-Statement im Java-Programm auftritt. Die anderen SQLs funktionieren problemlos.

Bei folgendem SQL-Select tritt der Fehler im Java-Programm auf. In einer anderen Umgebung (z.B. STRSQL oder Squirrel) funktioniert er:

select cast(IAARTN as char(10) ccsid 1141), cast(TSARTN as char(10) ccsid 1141) 
from LIB.DATEI1 A, LIB.DATEI2 B where A.IAARTN = B.TSRENR and IAFINR = 1
 and IAPGRU <> 0 and IASTYP = 1 order by A.IAARTN, B.TSARTN

Jetzt hab ich mal die FROM und WHERE Klausel etwas geändert (auf inner join), so dass aber trotzdem dasselbe Ergebnis rauskommt:

select cast(IAARTN as char(10) ccsid 1141), cast(TSARTN as char(10) ccsid 1141) 
from LIB.DATEI1 A inner join LIB.DATEI2 B on A.IAARTN = B.TSRENR and IAFINR = 1 where IAPGRU <> 0 and IASTYP = 1 order by A.IAARTN, B.TSARTN

Damit funktioniert's nun auch wieder im Java-Programm.
Kann mir das jemand erklären?

Gruß,
KM

[BenderD]

... wenn sich das im Java Programm und Squirrel wirklich unterschiedlich verhält (und das nicht an anderen Auswahlwerten etc. legt), dann müssen die Treiber unterschiedlich sein und der eine ist buggy.

D*B