SQL0901-Fehler

[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

[KM]

... 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.

Genau das hätte ich eigentlich auch erwartet. Aber beide Applikationen verwenden haargenau dieselbe jt400.jar in derselben Version. Deshalb versteh ich's ja nicht. Vor allem weil das Ding ja schon seit Jahren problemlos gelaufen ist und von heute auf morgen bei einem bestimmten SQL-Statement diesen ominösen SQL0901 erzeugt.

Gruß,
KM

[BenderD]

... naja, da gibt es schon noch möglicherweise abweichende Bedingungen:
- Treiber properties
- Parameter Werte (Typ!!! und Inhalt)
- verwendete Java Konstrukte (prepared oder nicht)
- Vorgeschichte der session
- Timeouts
normalerweise soööte der Blick ins Joblog des Serverjobs weiterhelfen.

D*B

[Fuerchau]

A.IAARTN = B.TSRENR
Artikel-Nr. = Rechnungsnummer?

Wie sehen die Originaltypen aus?
Der Fehler kann ja bei bestimmten Inhalten auftreten.

Wie ist eigentlich die CCSID des QZDA-Jobs?
Dann bringt ggf. der Cast auf 1141 nichts, da wieder in Job-CCSID gewandelt wird.

Außerdem hat das System manchmal Schwierigkeiten, wenn die Order-Felder nicht im Select enthalten sind, es ist zwar nun erlaubt aber man sollte es nicht tun.

Auch kann es Probleme geben, wenn die Ausdrücke keine expliziten Namen erhalten "cast(...) [as] ARTN".