-
SQLCODE bei Verarbeitung mehrere SQL
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
Code:
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;
-
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.
Code:
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
-
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
-
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.
-
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
-
Zitat von Hawi
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.
Last edited by xenofob; 08-05-20 at 13:01.
Grund: Smileys funktionieren nicht
-
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
-
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
-
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.
-
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.
Zitat von Fuerchau
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
-
Naja modern ist das jetzt nicht. Leave sollte man ja auch nur in absoluten Ausnahmesituationen verwenden, wenn man nach Allgemeinen Clean-Code Regeln entwickelt. (Was man ja unbedingt tun sollte, sonst kein RPG-Nachwuchs..)
Aber die Debatte tue ich mir nicht mehr mit RPG Entwicklern an, leider eine Diskussion ohne Aussicht auf Erfolg..
-
@xenofob
Ich will jetzt auch keinen Kleinkrieg anzetteln.
... aber was glaubst Du wohl ist leichter zu lesen bzw. zu ändern, FETCH/READ am Anfang der Schleife oder am Ende, wenn bereits 10 Bedingungen unter denen die Schleife verlassen und 20 Bedingungen unter denen ein Satz überlesen werden muss, definiert sind und Du eine weitere Bedingung unter der ein Satz überlesen werden muss einbinden musst?
Das kommt vielleicht nicht in PipiFax Progrämmchen vor, wie sie in der Schule gelehrt werden, aber in komplexen Anwendungen mit vielen verschiedenen Kunden, mit entsprechend vielen unterschiedlichen Anforderungen an ein Programm schon.
RPG-Programmierer sind ja alle so doof, die können keine 30 ineinander verschachtelte IFs lesen im Gegensatz natürlich zu allen anderen Programmierern!
Birgitta
Similar Threads
-
By mahones in forum NEWSboard Programmierung
Antworten: 31
Letzter Beitrag: 02-04-20, 10:21
-
By Hubert in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 14-10-19, 13:02
-
By nico1964 in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 29-06-15, 06:53
-
By Gimli in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 06-09-02, 11:58
-
By moskito in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 13-09-01, 17:40
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks