Es kommt kein negativer SQLCODE im ODBC-Treiber an.

"SQL Query changes in collation of errors might result in a SQL0802"
Ich interpretiere dies so, dass nun zusätzliche SQL0802 ausgelöst werden können, die vorher nicht erwartet wurden.
SQL0802 führt aber normalerweise zum Abbruch der Abfrage weil die Daten auf Grund des Dezimalfehlers nicht korrekt sein können und auch nicht sind!

select dec(10000, 3, 0) from sysibm/sysdummy1

Diese Abfrage führt zu einem gültigen Resultset mit NULL als Ergebnis!

Die Sache ist sogar noch viel schlimmer als ursprünglich gedacht.

Eine ODBC-Abfrage soll Datensätze laden.
Es kamen jedoch nur ca. 30.000 Datensätze an.
Bei der Analyse der Daten stellte man fest, dass Datensätze einfach fehlten.
Durch Ergänzung der Where-Klausel auf die fehlenden Sätze (nur so als Versuch) wurden diese nun auch tatsächlich geladen.
Nun kam ich ins Spiel, da man sich dies nicht erklären konnte.
Auffällig war zu erst mal, dass die Abfrage unheimlich lange benötigte.
Auf Grund dieser Performance habe ich eine Indexanalyse gemacht und den Index angelegt.
Diesen hat die AS/400 auch genommen und wohl auf Grund der geänderten Sortierfolge wurden nun ca. 42.000 Sätze geladen.
Allerdings fehlten immer noch jede Menge Daten!
Da man uns aus SOX-Gründen nicht so einfach auf die Maschine ließ, ging ich den Weg über den Opsnav. Schließlich kann man auch dort SQL's ausführen und es werden die Diagnosenachrichten angezeigt.
Mittels des OpsNav habe ich nun erstmalig den Dezimalfehler bemerkt, da dieser in der Diagnose auftaucht. Die Sätze selber wurden aber geladen und mit NULL in den relevanten Feldern.
Jetzt konnte ich erst der Ursache auf den Grund gehen und den Dezimalfehler (es war wie in obigem Beispiel ein CAST-Fehler wenn der Wert zu groß wurde) beheben.

Der Dezimalfehler trat nun nicht mehr auf, die Abfrage wurde erheblich schneller ausgeführt und es wurden nun 140.000 Sätze geladen!

Fazit:
Nicht nur, dass der SQL0802 nicht zum Abbruch führte, es wurde auch ein Großteil der Daten nicht übergeben!