Anmelden

View Full Version : SQL0901-Fehler



Seiten : [1] 2

KM
31-07-13, 08:51
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(JDE rror.java:703)
at com.ibm.as400.access.JDError.throwSQLException(JDE rror.java:669)
at com.ibm.as400.access.AS400JDBCStatement.commonExec ute(AS400JDBCStatement.jav
a:963)
at com.ibm.as400.access.AS400JDBCStatement.executeQue ry(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
31-07-13, 09:07
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
31-07-13, 09:27
ok, dann werde ich das SQL-Package mal löschen und neu erstellen lassen. Mal sehen wie es danach aussieht.

Vielen Dank,
KM

Fuerchau
31-07-13, 09:42
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
31-07-13, 11:16
... 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
31-07-13, 12:24
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
31-07-13, 13:56
Das ist en Problem denn der Default ist eben "mit SQLPKG", man muss es leider explizit ausschalten.

KM
31-07-13, 14:58
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/infocenter/iseries/v5r4/index.jsp?topic=/rzahh/javadoc/com/ibm/as400/access/doc-files/JDBCProperties.html

Fuerchau
31-07-13, 15:38
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
31-07-13, 19:01
Das verwenden wir in unserem Fall gar nicht.

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

D*B