SQLCODE bei Verarbeitung mehrere SQL

[Fuerchau]

Für mich gehört das Lesen an den Anfang der Schleife, da ohne GOTO bei Prüfbedingungen per "ITER" immer an den Schleifenanfang gesprungen werden kann.
Wenn das Lesen am Ende liegt, sehe ich dann häufig z.B. 2x Fetch/Read, 1x vor der Schleife und 1x am Ende und mitten drin komplizierte If's um für Prüfungen oder zum Überlesen wieder an den Ende-Read zu kommen.

In anderen Sprachen gibt es auch den "break" um eine Schleife zu verlassen und einen "continue" um an den Schleifenanfang zu gehen. Als Schleifen gibts dann "while(true) {}" oder "for(; ; ) {}" und niemand hält dies für schlechten Stil. Dies hat auch nichts mit RPG-Denke zu tun.

Was spricht also gegen Break und Iter?
Damit wird ein Code viel übersichtlicher und vor allem klarer.

Tja, und was Abbruch Bedingungen angeht, so kann man da auch noch mit Monitor-Gruppen arbeiten. Dies entspricht dann "Try {} catch (ex) {}", wobei der Finally{} noch fehlt.
Auch damit kann ich dann Close() bei Abbrüchen erreichen.

In ILE habe ich mir z.B. für das FileHandler-Problem das Konzept verinnerlicht:

dow CallRead(Buffer);
enddo;

dcl-proc CallRead;
dcl-pi *n ind;
Buffer ...
end-pi;

fetch ... into Buffer;
if sqlcode = *zero;
return *on;
endif;
// Logging !
return *off;
end-proc;

Somit habe ich den Read wieder am Schleifenanfang und kann Iter/Leave verwenden.

Dies kann man dann ebenso für alle anderen SQL's lösen und im Code liest sich das dann so:
if CallUpdate(Buffer);
endif;
if CallInsert(Buffer);
endif;
if CallDelete(Buffer);
endif;

Dann sieht's schon fast so schön wie C# aus. Und dies mache ich schon eine halbe Ewigkeit (auch seit RPG) so.

[BenderD]

... leave und iter - wo ist der Eimer.
Da macht man sich eine procedure, die gibt true zurück, wenn sie was gelesen hat und dann hat man:

dow liesWas();
machwas();
enddo;

Hat Dirk mal Turnschuhprogrammierung genannt - wer auch immer habe ihn selig - hat aber nicht nur mir gefallen.

D*B

[K_Tippi]

Ist zwar schon etwas älter,
aber ich schieb den SQLcode nach der Operation evtl in eine neue Variable.
damit kann ich dann zb. einen zweiten Fetch innerhalb einer weiteren der Schleife machen und der zweite FETCH beendet nicht meine erste Schleife
dou sqlcod_1 <> 0;
fetch f1 into ....
sqlcode_1 = sqlcode
dou sqlcode_2 <> 0
fetch f2 into....
sqlcode_2 = sqlcode
.....
enddo
enddo

[Fuerchau]

Mag nicht state of the art sein, aber meine Verfahren laufen so:

dow 1=1; // früher Do *hival
fetch ...
if sqlcode <> *zero;
leave;
endif;

// towas
if error;
iter;
endif;

enddo:

Vorteile:
- Bei Fehlern/nicht zuverarbeitenden Daten kann ich einfach an den Anfang springen.
- SQLCODE ist für die Schleifen nicht relevant.

[harkne]

So dann gebe ich auch noch meinen Senf zum Close cursor dazu.
Mein Close Cursor findet immer da statt wo ich ihn auch machen möchte und es logisch ist und zur Sicherheit noch vor dem OPEN CURSOR, in die PSSR und vor den *INLR.
Und ich bin auch schon daran verzweifelt als ich ein Programm geändert hatte warum das SQL immer noch nicht richtig funktioniert, dabei war der Cursor nicht geschlossen und er hat den bereits geöffneten verwendet. Deshalb auch die vielen CLOSE CURSOR.

[Fuerchau]

Bei Option Close Cursor mit EndMod ist das ja unnötig.
Nun ja, wenn man modular programmiert;-).

[B.Hauser]

Bei Option Close Cursor mit EndMod ist das ja unnötig.
Nun ja, wenn man modular programmiert;-).

... das ist unnötig! Weil natürlich auch der ODP mit dem *ENDMOD gelöscht wird!
... Und beim nächsten Durchlauf ein FULL OPEN gemacht wird, der 15-20% langsamer ist (weil der ODP wieder aufgebaut werden muss) als ein PSEUDO OPEN, bei dem nur die Daten in dem ODP aktualisiert werden.
... und gerade bei modularer Programmierung ist es gerade sinnvoll die ODPs nicht zu löschen! Die gleiche kann aus den Prozedur aus den unterschiedlichsten Programmen/Prozeduren aufgerufen werden.

Birgitta

[Fuerchau]

Tja, ein ODP hat mit dem Cursor-Close aber auch gar nichts zu tun. Ein ODP bleibt ab einem 2. Open immer offen.