SQL V7R1 arbeitet bei Dezimalfehler einfach weiter

[Fuerchau]

Früher war alles besser?
Bei einem SQL kommt es zu dem Fehler SQL0802 Fehler bei Datenumsetzung oder beim Zuordnen von Daten, Art 1=Arithmetischer Überlauf!
Der vorausgegangene Fehler ist ein CPF5035 "Datenzuordnungsfehler in Teildatei XXXX."

Der Fehler ist nicht das Problem, ich weiß dass er auftreten kann.
Aber wie veranlasse ich SQL nun, diesen Fehler auch an mein Programm zu melden und nicht einfach den NULL-Wert zu generieren?
Das Problem ist hier, dass die Anwendung davon ausgeht, dass alles i.O. ist denn der NULL-Wert kann auch vorkommen.

Nun verschärft sich das ach noch, dass per ODBC zugegriffen wird, d.h., die Fehler stehen zwar schön im Joblog (falls überhaupt Debug eingeschaltet ist!) werden aber nicht weitergereicht.

Probierts einfach mal aus:

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

bei STRSQL wird "++++++" angezeigt, was ja auf Fehler hindeutet, bei ODBC wird NULL ohne Fehler gemeldet.

Lange Rede kurzer Sinn, bis V6 bekam ich eine SQL-Abbruchmeldung, seit V7R1 arbeitet die Anwendung leider weiter.
Wie bekomme ich bei SQL0802 nun wieder eine Abbruchmeldung?

[BenderD]

... soll ich das so interpretieren, dass Du keinen auswertbaren SQLCODE zurück bekommst?

D*B

[Fuerchau]

Stimmt auffallend.
Wenn man mal nur SQL0802 googelt kommt man auf viele Beiträge, die SQL0802 als Exception bekommen. Ich kann mich auch erinnern, dass dies bis V6R1 auch so war.
Seit V7R1 wird diese Info im Joblog nur noch als "Diagnose"- Nachricht und nicht als Exception aufgeführt. Wie gesagt, wenn man den DEBUG-Modus ausschaltet kommt die Fehlermeldung gar nicht.
Im embedded SQL kann ich ja im Null-Anzeiger zwischen -1 (NULL) und anderen negativen Werten unterscheiden. Bei ODBC gibt's keinen NULL-Anzeiger sondern das Feld hat den Wert DBNull.
Leider geht aber die Unterscheidung SQL0802 oder echtem NULL verloren.

Übrigens, wenn solche Fehler in den Daten vorkommen, verlängert sich die Laufzeit der Abfrage um Faktor 100 (wobei das nun wieder kein echtes Indiz ist).

Auch im STRSQL hat SQL bei den meisten Datenfehlern abgebrochen und nicht weitergemacht.

[TARASIK]

Hallo Baldur,
dieser Hinweis aus Memo to Users V7R1M0 kann Dir nicht weiterhelfen ?

SQL Query changes in collation of errors might result in a SQL0802
A change was made to not collate errors for SQL queries with ordering, distinct, or aggregation. This was
done to avoid providing unpredictable or wrong results when a result in error cannot be included in
ordering, aggregation, or distinct result sets. A selection error is now signaled in this scenario, using the
SQL0802 message with SQLCODE=-802 and SQLSTATE=’22003’. The SQL0802 message will be preceded
by CPF5035 and CPD4019 escape messages.
To allow compatibility with previous behavior, a new QAQQINI option, COLLATE_ERRORS, is available.
COLLATE_ERRORS -
Specifies how data errors are handled on the GROUP BY and ORDER BY expression
during hash or sort processing within queries.
Supported values:
v
*DEFAULT - The default is *NO.
v
*NO - A value of *NO causes the query to be ended with an error when a grouping or ordering
expression results in an error.
v
*YES - A value of *YES indicates that the grouping or sort continues.

[BenderD]

... das ist mir noch ein wenig von Präzision entfernt. SQL hat per Standard gewisse Fehlerregularien und dazu gehört, dass Ausnahmebedingungen frei nach Theorie per SQLState - davon sind wir weit entfernt, meist ist der SQLCode verwertbarer - signalisiert werden. Programm Ausnahme Bedingungen sollen da eher nicht - hängt wieder von der Programmiersprache ab - auftreten. Bei ODBC - und JDBC - wird das dann real auf den Treiber verlagert - wenn da nix kommt, sollte man erst mal selbigen wechseln. Das Joblog des Serverjobs taugt da nicht als Quelle; nochmal die klare Frage: kommt da ein negativer SQLCode in Deiner Appliaktion an - Deine Rede sei jaja oder neinnein?

D*B

[Fuerchau]

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!

[BenderD]

... aus meiner Sicht ein Fehler des Treibers. Das Sätze geliefert werden und mittendrin was passiert ist normal (es wird satzweise geliefert und weder Treiber noch Datenbank können wissen, dass da noch Schrott kommt), dass die Anzahl der Sätze differieren könnte ist eine Folgerung davon, das mit den falschen Werten ist grenzwertig, liegt aber in der Natur der Sache. Eindeutig falsch ist, dass kein SQLCODE geliefert wird.

D*B

[Fuerchau]

Bzgl. der Treiber habe ich nur 2 zur Auswahl, den CA-ODBC-Treiber und den CA-OLEDB-Treiber.
Beide liefern das selbe Ergebnis.
Auch der OpsNav (ich denke mal der arbeitet mit JDBC) liefert keine Fehler sondern nur die Daten.
Mal sehen was der JDBC-Treiber von CA dazu sagt.

[mk]

Hallo,

die Meldung -802 kommt auf jeden Fall.

Eventuell könnte man die MSG und deren Wertigkeit ändern damit es zu einem Abbruch kommt.
Ist vllt. ein Versuch Wert.

Gruß
Michael

[Fuerchau]

So, nun habe ich das Problem näher eingekreist und werde einen entsprechenden Fehler an die IBM geben lassen.
Mit den Microsoft ADO-Objekten habe ich 2 sog. Cursorvarianten:
ClientCursor = Microsoft lädt alle Daten in das Resultset
ServerCursor = Die Daten werden erst beim MoveNext abgeholt

Beim ClientCursor komme ich über den "kaputten" Datensatz nicht hinaus, das ist auch korrekt.
Beim ServerCursor (in .NET/Java ist das nur der Reader) kann ich alle Daten ohne Fehler lesen, einen SQLState gibt's da nicht, nur den besagten NULL-Wert.
Nun kann ich die Anwendung nicht auf ClientCursor umstellen, da Millionen Sätze nicht in den Speicher geladen werden können, ganz abgesehen von der dann schlechten Performance.

Lade ich die Daten nun in Excel mit der normalen Funktion "Externe Daten abrufen" wird weder in MS-Query noch in Excel ein Fehler bemerkt.
Die Daten sind halt einfach falsch und damit wird dann gearbeitet.

[Fuerchau]

Ich habe das nun auch noch mit SQLRPGLE probiert, der SQLCOD ist 802 und nicht -802!
Der entsprechende NULL-Anzeiger steht dann auf -2 (Datenverlust).
ODBC kennt sowas ja nicht und positive SQLCodes sind ja nur Warnungen.

[Fuerchau]

Nun ja, von der IBM gibt's die erste Meldung die allerdings keinen Unterschied brachte.
Anscheinend kennen die ihre eigenen ODBC-Einstellungen nicht.

Hat jemand noch Zugriff auf V6R1 und V5R4 um folgenden Befehl z.B. als Excel-Import per ODBC auszuprobieren und das Ergebnis hier zu posten?

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

Ziel ist, dass dieser einen SQL0802 auslöst, was laut IBM ab V6R1 kein Fehler sondern nur eine Warnung ist, also als positiver SQLCOD gemeldet wird.