SQL V7R1 arbeitet bei Dezimalfehler einfach weiter

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

[BenderD]

... auf Holgers PUB1 V5R4 kommt da auch ein +802 mit SQLSTATE 01519 (warning) durch; ANSI korrekt wäre ein SQLSTATE class 22 (data exception). Was den SQLCODE angeht, scheinen das typische Abnutzungserscheinungen des SQLCODE Würfels zu sein, da muss der Strich nachgezogen werden. Was den SQLSTATE angeht, da geht es sowieso auf allen Datenbanken drunter und drüber. Am besten schneidet da noch PostgreSQL ab.

D*B

[B.Hauser]

Sowohl in Release V5R4 als auch in Release 7.2 wird der SQLCODE -802 ausgegeben, wenn keine Indikator-Variable verwendet wird.
Wird mit Indikator-Variable gearbeitet wird in beiden Releasen der SQLCODE +802 ausgegeben.
Der Wert der Indikator-Variable wird in beiden Releasen mit -2 (Datenmapping) ausgegeben.

Und das ist korrekt, deshalb werden Indikator-Variablen ja verwendet.

Birgitta

[Fuerchau]

Bei ODBC/JDBC hat man jedoch keinen Einfluss auf Indicator-Variablen, hier werden diese ja grundsätzlich verwendet.
Der Wert der Variablen wird mit NULL zurückgegeben.
Es ist daher unmöglich, per ODBC/JDBC festzustellen, ob der Wert NULL korrekt oder auf Grund eines Datenfehlers entsteht.

[holgerscherer]

Moment. PUB1.DE ist V5R3 ;-)

[Pikachu]

Moment. PUB1.DE ist V5R3 ;-)

Das ist vielleicht auch ein Fehler.

[holgerscherer]

Das ist vielleicht auch ein Fehler.

Nein, das ist limited by design <g>

Ich vermute eher, dass Baldur Recht hat und es auch innerhalb der Releases gewisse Unterschiede bezüglich PTF gibt. Bei V5R4 bin ich mir sogar recht sicher, erinnere mich nur nicht mehr genau an den PTF-Stand; da gab es diverse Änderungen im SQL. Vielleicht kann Biggi einen Einwurf bringen?

-h

[Fuerchau]

So hier nun eine Antwort von IBM (es dauert halt manchmal etwas):

"wir haben das Problem mit Ihrer Dokumentation und Re-create Steps nach Rochester gegeben. Unsere
Entwickler pochen darauf das unser ODBC Treiber in allen Log Dateien und Traces
den SQL0802 mit Ursache als Information mit Warnung ausgibt.

Das kann auch mit dem ODBC Testprogramm von Microsoft nachvollzogen werden. Die
Problmatik wie Sie schon richtig erkannt, daß die Anwendung/Zwischenschicht
nicht auf die Warnung reagiert. "

Mal sehen, ob sich noch weitere Möglichkeiten ergeben.

[Fuerchau]

So, nun ist die Antwort aus Rochester da:
Es wird nichts geändert, es ist alles i.O.!

Mit anderen Worten:
Wenn es denn bei Autocast's zu einem positiven SQL0802 kommt, dann muss man bei ODBC halt damit leben, dass die Anwendung nichts davon merkt und somit ggf. mit falschen Daten weiterarbeitet.

Das sind ja schöne Aussichten für zukünftige Fehler die die IBM da einbauen kann.
Auf die Daten per SQL ist dann kein Verlass mehr sobald man UDF's oder Cast's verwendet oder Autocasts eingesetzt werden und ein SQL0802 ausgelöst würde.

Nicht sehr zufriedenstellend ins besonders da der Fehler ja erst mit dem Wechsel von V6R1 zu V7R1 erzeugt wird.