SQLCODE bei Verarbeitung mehrere SQL

[Hawi]

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]

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]

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

[xenofob]

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.

[B.Hauser]

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

[Hawi]

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]

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]

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

[xenofob]

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

[B.Hauser]

@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

[camouflage]

... da wäre ich doch völlig schmerzfrei und füge zwei fixe Statements ein: GOTO (evtl. auch mit einem Indikator konditioniert) und einen TAG. ;-)

[manuel.marcos]

Also GOTO / TAG Verwendung würde ich persönlich versuchen zu vermeiden und geht ja zum Glück im fully-free auch nicht mehr
Aber die Verwendung von leave bzw. iter finde ich, unabhängig von der Programmiersprache (break/continue), überhaupt nicht abwegig. Wenn ich zu Beginn einer Schleife feststelle das ich raus muss oder zum nächsten Schleifendurchlauf, dann besser ein leave/iter als den ganzen Rumpf unnötig zu verschachteln.