View Full Version : SQLRPGLE Problem mit SQL Communication Area
Hallo zusammen,
in einen SQLRPGLE Programm nutze ich sowohl in SubRoutinen und in SubProcedures SQL-Abfragen.
Allerdings "versaut" mir die SubProcedure die SQLCA die um den Aufruf auch benutzt wird.
Wenn in der Procedure der SQLCODE=100 auftritt und ich um den Aufruf rum den SQLCODE ebenfalls Abfrage bekomme ich das Problem!
Wie kann ich das elegant umgehen?
Danke an alle Helfenden!
Kurzes Bsp.:
DOW SQLCODE > 0 AND SQLCODE <> 100
FETCH ....
EVAL VAR = getWert(xxx)
ENDDO
P getWert B
d...
Exec-SQL Select SUM(sss) from FILE where xx;
P getWert E
andreaspr@aon.at
06-03-14, 14:01
Speichere dir doch den SQLCODE in eine Variable damit du es später prüfen kannst.
Oder mache sowas wie ...
if (sqlcode <> 0);
endeSchleife = *on;
endif;
Auf die SQLCA sollte auch nur gleich nach der SQL Anweisung zugegriffen werden.
Und im übrigen hat deine Schleife Potential zu einer Endlos-Schleife.
lg Andreas
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;
Die SQLCA wird mit jedem (embedded) SQL Statement, das ausgeführt wird upgedated, sozusagen ein Ausgabe-Parameter aus dem SQL-API, das aufgerufen wird.
Deshalb sollten Informationen aus der SQLCA, sofern diese verwendet werden müssen immer unmittelbar nach dem SQL-Statement entweder geprüft oder in ein eindeutig zuordenbares HilfsFeld umgeladen werden.
Birgitta
Wie kann ich das elegant umgehen?
Für jede View ein eigenes Datenzugriffsmodul mit den entsprechenden Procedures für read/write/update/delete und den anderen benötigten Routinen.
D*B
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
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
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