PDA

View Full Version : SQLCODE bei Verarbeitung mehrere SQL



Seiten : [1] 2 3

Hawi
08-05-20, 11:53
Moin zusammen,

ich bin gerade auf ein "Problem" bei nachfolgendem Code gestoßen und habe dazu mal eine Frage.

Das Programm läuft so bis zu dem Zeitpunkt, wo innerhalb der Funktion $Update_LAGPT der sqlcode 100 auftritt, der dort als "ok" eingestuft wird.

Da der sqlcode aber gefüllt ist, wird dann natürlich auch die innere Schleife beendet, ohne weitere fetch next und dann auch close cursor auszuführen.

Beim nächsten Durchlauf der der äußerenSchleife scheitert dann natürlich der open cursor, da dieser ja noch offen ist.

Gibt es eine elegante Möglichkeit, den sqlcode nicht immer explizit auf 0 setzen zu müssen, wenn mich das Ergebnis eines sql's auf eine bestimmte Datei eigentlich nicht interessiert, aber für die allgemeine Programmverarbeitung doch noch gebraucht wird?

Beim fetch selbst hatte ich bereits daran gedacht, den sqlcode auf 0 zu setzen, jedoch weiß man ja nicht zwangsläufig, ob dieser in aufgerufenen Funktionen noch gesetzt wird und auch so bleibt.

Im "normalen" RPG nehme ich halt %EOF(Dateiname) oder %Found(Dateiname).
Da gibt es dann keine Problme mit Überschneidungen.

Ich hoffe, ich habe einigermaßen verständlich ausgedrückt, worum es mir geht.

Danke und Gruß
Michael



DOW sqlcode <> 0;
Diverse SQL bis hier


if not $defineCursorRGZPT();
return false; // Fehler (bereits behandelt => Programmende)
endIf;

doW sqlCode = 0;

// Lesen nächste Rechnungszeilenpartie
exec sql fetch rgzpt_Cursor into :sqlRecRZP;

if sqlCode <> 0;

if sqlCode = 100; // = EoF
exec sql close rgzpt_Cursor;

if sqlCode = 0; // = EoF
$protokolliere( '* SQL-Cursor RGZPT für Umfuhr '
+ %char(sqlrecAK.akatnr)
+ ' erfolgreich entfernt');
else;
$protokolliere( '* SQL-Cursor RGZPT'
+ ' konnte nicht entfernt werden');
endif;

sqlcode = 0; // sicherheitshalber wegen Hauptschleife wieder auf 0
leave;
endIf;

// Andere Fehler
$protokolliere('Fehler beim Fetch Next, Datei RGZPTPF. '
+ 'SQLCode: ' + %char(SqlCode)
+ ' - SQLState: ' + SqlState
+ '. ' + SQLLIB_getLastSQLError()
);
return false; // => Programm abbrechen
endIf;

// Aktualisieren der Abgangsmenge bei Lagerpartie
innerhalb der Funktion kann auch auch sqlcod <>0 entstehen, was aber ok sein kann
if not $Update_LAGPT( sqlrecRZP.rzpfrm : sqlrecRZP.rzpartnr
: sqlrecRZP.rzplager : sqlrecRZP.rzpptnr
: sqlrecRZP.rzpmgeve);

return false;

endIf;

enddo;

ab hier weitere Verarbeitung nach Abarbeitung aller Sätze des fetch.
Diverse SQL ab hier

enddo;

andreaspr@aon.at
08-05-20, 12:16
Hi Michael,

eleganter wäre es wenn grundsätzlich der sqlcode immer nach der jeweiligen SQL Anweisung geprüft wird und nicht erst später.
Du kannst dir nie sicher sein wo noch überall der sqlcode geändert wird und wehe jemand ändert irgendwann mal den code und vergisst darauf.

Besser also generell so programmieren, dass du darauf nicht acht geben musst.



fetch ...;
dow sqlcode <> 0;
//dein code
fetch ...;
enddo;


Das if sqlCode = 100; kannst du dann auch hinter der Schleife verschieben.
Ersparst dir dann auch das LEAVE.

lg Andreas

Hawi
08-05-20, 12:28
Moin Andreas,

zunächst danke für die rasche Antwort.

Ich glaube, über Programmierstile muss man nicht streiten *frech grins*

Ich habe damals noch DO *Hival gelernt und das ist bei mir so sitzen geblieben. Da musste ich mich um das Handling dann auch explizit kümmern. Ich persönlich mag das Read vor dem Doxx und am Ende vor dem Enddo auch nicht wirklich.

Nachdem ich den Post geschrieben habe, habe ich auch generell de close cursor schon hinter das enddo verschoben, da das dann auch innerhalb der Schleife etwas aufgeräumter aussieht und sowie generell passieren soll.

Trotzdem beantwortet das nicht meine eigentlich Frage.

Das SQL innerhalb der aufgerufenen Funktion produziert halt ggf. auch einen sqlcode 100, der mich dort aber nicht interessiert.

Komme ich dann zurück, würde auch in Deinem Code das enddo "überlaufen", was aber nicht gewollt ist.

Entsteht in der Funktion ein sqlcode <> 0/100 ist die Funktion auch "false" und darauf reagiere ich dann ja auch.

Die Frage ist eigentlich "ein sqlcode" für alle sql für verschiedene Datenquellen"?

lg
Michael

xenofob
08-05-20, 12:40
Komme ich dann zurück, würde auch in Deinem Code das enddo "überlaufen", was aber nicht gewollt ist.

Naja bedingt. Du würdest ja anschließend den nächsten Satz fetchen. Das würde das SQLCOD-Ergebnis wieder überschreiben. Überlaufen würde es nicht.

Aber zu deiner Frage -> Mir ist nicht bekannt dass sowas möglich ist (wüsste auch nicht wie die Syntax aussehen sollte, ist ja ne variable die man abfragt..).
Du könntest dir mit Zwischenspeichern des SQLCOD in ein selbstdefiniertes SQLCOD1 (oder was auch immer) zumindestens weiterhelfen.

Hawi
08-05-20, 12:46
xenofob, Du hast natürlich Recht. Da habe ich nicht zuende gedacht.

Das würde dann für die Vorgehensweise von Andreas sprechen.

Danke für den Hinweis

B.Hauser
08-05-20, 12:46
Hallo Michael,

vielleicht noch so ein einfacher Trick, um sicherzugehen, dass der Cursor auch wirklich geschlossen wurde.
... mach einfach ein CLOSE vor dem OPEN.
War der Cursor noch geöffnet, dann ist er jetzt geschlossen.

Es gibt nur einen einzigen SQLCODE.
Dieser ist in einer globalen Datenstruktur hinterlegt und wird bei jedem SQL-Aufruf (bzw. den entsprechenden Progrmmen) erneut ausgegeben.
Qualifizieren oder eindeutig einem Cursor zuweisen kann man nicht.

Birgitta

xenofob
08-05-20, 12:59
xenofob, Du hast natürlich Recht. Da habe ich nicht zuende gedacht.

Das würde dann für die Vorgehensweise von Andreas sprechen.

Danke für den Hinweis

Ja die Vorgehensweise von Andreas ist weit verbreitet. Zu recht.
In der Schule erlernt man genau diese Art von Schleifenverarbeitung. (sogar unabhängig von RPG)

Wenn du dich damit anfreunden könntest, ist nicht nur dir, sondern auch allen zukünftigen jungen Kollegen geholfen.

Hawi
08-05-20, 13:02
Hallo Birgitta,

danke für den Tipp.

Darüber nachgedacht hatte ich auch schon, da ich gleiches zum Programmende auch mache, unabhängig davon, ob ich vorher schon den close hatte.

Und da ich den sqlcode dann ja nicht auswerten muss, läuft der "Cursor ... nicht geöfnnet" dann halt ins Leere.

So werde ich das dann wohl machen.

Glücklich macht mich das zwar nicht wirklich, aber an SQL kommt man ja auch nicht mehr wirklich vorbei und eigentlich ist es ja auch ganz nett und dazu nahezu plattformunabhängig.

Aber da ich weiß, dass Du sehr viel mit SQL machst und ich auch schon auf einigen Deiner Vorträge auf der COMMON war, vieleicht magst Du mir da noch eine Frage beantworten, die mir schon länger im Kopf schwirrt, die ich aber mit niemanden wirklich ausdiskutieren kann.

Hat Embedded-SQL in einer Anwendung, die rein aus RPG(LE) und DDS-beschriebenen Files besteht einen wirklichen Vorteil gegenüber der herkömmlichen Dateiverarbeitung?

Über eine Antwort würde ich mich freuen. Wenn Du magst, auch gerne als pn, da es das Thema hier nicht wirklich betrifft.

Danke und Gruß
Michael

P.S. ich weiß, dass ich den abschließenden close am Programmende auch vom System machen lassen kann, musste aber eh Aliasse lösche und habe es dann dort gleich mit rein gebaut

Fuerchau
08-05-20, 13:50
Da es den DO *HIVAL nicht mehr gibt, verwende ich grundsätzlich

exec sql open ...
dow 1=1;
exec sql fetch ...
if sqlcode <> *zero;
leave;
endif;
:
enddo:
exec sql close ...

Somit frage ich den SQLCODE nur da ab, wo ich ihn brauche.

Hawi
08-05-20, 14:01
Danke Fürchau,

das ist ja genau meine Art Code zu schreiben *smile* und würde mir in meinem konkreten Fall weiterhelfen.

Die Frage mit den sqlcode in der globalen DS hat ja leider schon Birgitta, wie von mir befürchtet beantwortet.


Da es den DO *HIVAL nicht mehr gibt, verwende ich grundsätzlich


Was natürlich nur dann so stimmt, wenn man nicht mehr fixed programmiert/programmieren muss