SQL ROLLBACK im embedded SQL mit SQL Prozeduraufruf

[harkne]

Hallo zusammen,

ich rufe eine SQL Prozedur auf welche einen INSERT von einer Datei in eine andere Datei macht.
Diese SQL Prozedur wird aus dem RPG mehrfach in einer Schleife aufgerufen.
Wenn ein Fehlerfall eintritt mache ich einen execute sql rollback.
Aber der Rollback löscht die vorherigen Sätze nicht.

Ich denke das Problem hängt mit der SQL Prozedur zusammen.
Muss ich in der Prozedur was angeben, dass die Sätze unter COMMIT laufen?

Vielen Dank

[Fuerchau]

commit = *chg;

Beachte noch folgendes:
Bei einem Rollback / Commit wird der aktuelle Cursor geschlossen!
Man kann den Cursour zwar mit "declare cursor meincursour with hold for" definieren, das hilft aber nur beim Commit. Beim Rollback wird der Cursor dann auch geschlossen.
Ich behelfe mir dann mit einem Savepoint und einem Rollback to Savepoint retain cursor.
Dann bleibt beim Rollback der Cursor auch offen.

Wenn du einen Rollback in der Prozedur machst, hat du keine Chance den Cursor offen zu halten.
SQL-Prozeduren sollten auch keinen Commit/Rollback machen, sondern die Anwendung, die die Prozedur verwendet.

[Andreas_Prouza]

Bei Commit prüfe ich auch (gerade bei Prozeduren) die ACTGRP.
Das Commit betrifft alle Änderungen von allen Programmen innerhalb der gleichen ACTGRP.
Wenn es also eine Prozedur ist, die für sich abgekapselt sein soll, sollte diese in einer eigenen ACTGRP laufen.

[BenderD]

commit = *chg;

Beachte noch folgendes:
Bei einem Rollback / Commit wird der aktuelle Cursor geschlossen!
Man kann den Cursour zwar mit "declare cursor meincursour with hold for" definieren, das hilft aber nur beim Commit. Beim Rollback wird der Cursor dann auch geschlossen.
Ich behelfe mir dann mit einem Savepoint und einem Rollback to Savepoint retain cursor.
Dann bleibt beim Rollback der Cursor auch offen.

Wenn du einen Rollback in der Prozedur machst, hat du keine Chance den Cursor offen zu halten.
SQL-Prozeduren sollten auch keinen Commit/Rollback machen, sondern die Anwendung, die die Prozedur verwendet.

... beim rollback muss dann ebenfalls hold angegeben werden und (wenn ich das richtig erinnere) muss der cursor for dem fetch next repositioniert werden.

D*B

[harkne]

Der commit und der rollback werden im RPG gemacht und es wird auch nicht weiter gemacht.

Schleifenbeginn
Aufruf der SQL-Prozedur
Es gibt einen Fehler --> exec sql rollback und Programm verlassen
Schleifenende
exec sql commit und Programm verlassen

Der Rollback wird ausgeführt aber die Daten bleiben weiterhin in der Datei das ist das Problem

Das aufrufende CL startet mit actgrp(*new)
Das rpg mit actgrp(*caller)

Jetzt mal noch ne dumme Frage hahaha. Benötige ich einen STRCMTCTL im CL-Programm wenn ich commit und rollback nur über SQL mache?

[BenderD]

Der commit und der rollback werden im RPG gemacht und es wird auch nicht weiter gemacht.

Schleifenbeginn
Aufruf der SQL-Prozedur
Es gibt einen Fehler --> exec sql rollback und Programm verlassen
Schleifenende
exec sql commit und Programm verlassen

Der Rollback wird ausgeführt aber die Daten bleiben weiterhin in der Datei das ist das Problem

Das aufrufende CL startet mit actgrp(*new)
Das rpg mit actgrp(*caller)

Jetzt mal noch ne dumme Frage hahaha. Benötige ich einen STRCMTCTL im CL-Programm wenn ich commit und rollback nur über SQL mache?

... lass mich raten: Du hast die procedure mit commit level *none erstellt.

D*B

[Fuerchau]

Das Programm, dass die Prozedur aufruft, entscheidet über den Commitlevel.
Die Prozedure erbt i.d.R. vom Aufrufer.

Prüfe einfach mal, ob du im Programmcode:

exec sql set option commit = *chg;

verwendest. Der Default ist leider *none.
Und wichtig ist natürlich auch, dass die Tabellen in einem Journal aufgezeichnet werden.
Ohne Jounrnal keine Transaktionen.

[BenderD]

Das Programm, dass die Prozedur aufruft, entscheidet über den Commitlevel.
Die Prozedure erbt i.d.R. vom Aufrufer.

Prüfe einfach mal, ob du im Programmcode:

exec sql set option commit = *chg;

verwendest. Der Default ist leider *none.
Und wichtig ist natürlich auch, dass die Tabellen in einem Journal aufgezeichnet werden.
Ohne Jounrnal keine Transaktionen.

... es geht wieder einmal alles durcheinander:
- default bei SQL ist commit *chg (wird aber von Dilettanten oft auf *none geändert)
- SQL Procedures und Functions erben das commit level aus der Erstellungsumgebung. Profis schreiben das SQL Statement in eine SRCPF und erstellen die Procedure/Function mit RUNSQLSTM ohne verhunzte defaults und dann passt das.
- Versuche commit ohne Journal zu starten enden zum Glück ohne Schaden anzurichten - nämlich sofort.

D*B

[harkne]

Hallo, ja aber ich war schneller haha
Die Prozeduren hatten COMMIT = *NONE.
Ich entschuldige mich damit, dass ich die Prozeduren nicht gemacht habe. hahaha
Aber ja, das war das Problem.
Vielen Dank für die Hilfe