SQLRPGLE Problem mit SQL Communication Area

[BenderD]

Ich mache das meist anders:

dow 1=1;
exec sql fetch ...;
if sqlcode <> *zero;
leave;
endif;
// tuwas (Hier kann SQLCOD ruhig verändert werden
sqlcode = *zero;
enddo;

dow liesWas();
machWas();
endDo;

P lieswas b
d result n inz(FALSE)
exec sqll fetch...
if sqlcode = 0;
result = TRUE;
return result;
p lieswas e

Turnschuhprogrammierung (in Memoriam Dirk) ganz ohne leave, iter und rettSQLCODE!

D*B

[B.Hauser]

Egal welche Methode Ihr wählt, Ihr solltet nicht auf SQLCODE = *Zeros oder SQLCODE <> *Zeros abfragen, sondern auf SQLCODE < *Zeros (für Fehler) und SQLCODE = 100 (für nicht gefunden).

Der Grund dafür liegt darin, dass es vereinzelt Situationen gibt, in denen eine Warnung (SQLCODE > *Zeros und <> 100) ausgegeben wird. In diesen Fällen werden trotzem Daten, die verarbeitet werden ausgegeben. Zukünftig kann dies vielleicht noch häufiger als heute der Fall sein.

Birgitta

[BenderD]

Egal welche Methode Ihr wählt, Ihr solltet nicht auf SQLCODE = *Zeros oder SQLCODE <> *Zeros abfragen, sondern auf SQLCODE < *Zeros (für Fehler) und SQLCODE = 100 (für nicht gefunden).

Der Grund dafür liegt darin, dass es vereinzelt Situationen gibt, in denen eine Warnung (SQLCODE > *Zeros und <> 100) ausgegeben wird. In diesen Fällen werden trotzem Daten, die verarbeitet werden ausgegeben. Zukünftig kann dies vielleicht noch häufiger als heute der Fall sein.

Birgitta

... davon rate ich ab!!! Ein warning darf nur ignoriert werden, wenn ich weiß, dass es unschädlich ist (z.B.: SQLCODE + 088 beim Update) ein unbekanntes warning ist immer Fehler! Ich empfehle einen Blick in TFM. Grundlage fast aller warnings ist ungenaue Programmierung (hat nur fast geklappt) oder Datenschrott (könnte vielleicht passen).

D*B