SQL V7R1 arbeitet bei Dezimalfehler einfach weiter

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

[mk]

HI

also bei V7R2 wird ein negativer SQLCOD ausgegeben
SQLCOD = -000000802.

[KingofKning]

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.

Also ich bekomme 00001 zurück unter V5R4. Sehe keine Fehlermeldung

GG

[Fuerchau]

Da scheint das bei V7R2 ja wohl behoben zu sein. Mal sehen, wann es das PTF dann für V7R1 gibt.

Ich habe nun noch mal das Ankündigungsschreiben für V6R1 analysiert:

3.11.24 SQL Query changes in collation of errors might result in a

SQL0802

In PTF MF45590, a change was made to not collate errors for SQL queries

with distinct or aggregation. This was done to avoid providing wrong

results when a result in error can not be included in aggregation or

distinct result sets. A selection error is now signalled 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 by PTF.

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:

* *DEFAULT - The default is *NO.

* *NO - A value of *NO causes the query to be ended with an error when

a grouping or ordering expression results in an error.

* *YES - A value of *YES indicates that the grouping or sort continues.

Da steht nichts davon das SQL0802 nun positiv gesetzt wird oder verstehe ich da was falsch?

[Fuerchau]

Ich konnte das nun noch mal auf V5R2 ausprobieren (ja, solche Kunden gibt's noch).
Da kommt tatsächlich auch kein Fehler.
Das deckt sich mit obiger V5R4-Aussage.

Gut, hoffe ich mal auf das PTF aus V7R2.

[mk]

Hi,

gearde nochmal mit einem kleinen Progrämmchen auf einem V5R4 und auf einem V7R1 System probiert

danum             s              3  0    
dx                s              1       
                                         
C/EXEC SQL                               
C+ select dec(10000, 3, 0) into :aNum    
c+ from sysibm/sysdummy1                 
C/END-EXEC                               
                                         
c     'sqlcod'      dsply                
                                         
 *                                       
c                   Eval      *INLR = *ON 

Beide Systeme liefern den SQLCOD im Debugger
SQLCOD = -000000802.

Gruß
Michael

[Fuerchau]

Da gibt's also auch bei V5R4 anscheinend unterschiedliche PTF-Stände bzgl. dieses Fehlers.