Wie bekomme ich Record-Locking mit embedded SQL hin?

[dschroeder]

Bei SQL basierten Zugriffen verwenden wir in der Regel Zugriffsmodule, die lesen, schreiben, sperren, und löschen. Wenn ein Job, der eine Sperre eingetragen hat, nicht mehr aktiv ist, gilt die Sperre nicht mehr und wird automatisch aufgeräumt.

Aber zu den Datenbanksperren mit SQL: Ich komme also nicht drum herum, Programme, in denen ich SQL-Sperrungen haben möchte, speziell zu kompilieren. Ist etwas unschön, aber was will man machen ...

Vielen Dank für eure Antworten. Ich drohe schon mal damit, demnächst vielleicht mit weiteren Fragen dazu auf das Forum zuzukommen.

LG, Dieter

[BenderD]

Bei SQL basierten Zugriffen verwenden wir in der Regel Zugriffsmodule, die lesen, schreiben, sperren, und löschen. Wenn ein Job, der eine Sperre eingetragen hat, nicht mehr aktiv ist, gilt die Sperre nicht mehr und wird automatisch aufgeräumt.

Aber zu den Datenbanksperren mit SQL: Ich komme also nicht drum herum, Programme, in denen ich SQL-Sperrungen haben möchte, speziell zu kompilieren. Ist etwas unschön, aber was will man machen ...

Vielen Dank für eure Antworten. Ich drohe schon mal damit, demnächst vielleicht mit weiteren Fragen dazu auf das Forum zuzukommen.

LG, Dieter

... da gibt es nix mit anders koompilieren, das kann man in der Quelle mit sql options regeln. Ich rate allerdings dazu, das dann richtig zu machen.
1.) den Unfug mit dem geänderten command default beim CRTSQLRPGI abzustellen und den COMMIT(*NONE) in die SQL Options zu stellen.
2.) Dann werden die obigen Programme simple mit default gewandelt.
3.) Das Commit(*NONE) richtigstellen und mit commit arbeiten.

D*B

[dschroeder]

... da gibt es nix mit anders koompilieren, das kann man in der Quelle mit sql options regeln. Ich rate allerdings dazu, das dann richtig zu machen.
1.) den Unfug mit dem geänderten command default beim CRTSQLRPGI abzustellen und den COMMIT(*NONE) in die SQL Options zu stellen.
2.) Dann werden die obigen Programme simple mit default gewandelt.
3.) Das Commit(*NONE) richtigstellen und mit commit arbeiten.

D*B

Das klingt gut. Vielen Dank!
Ich werde das mal ausprobieren.

Schönen Abend an alle.

[Fuerchau]

Du kannst ja nach dem Fetch des For-Update-Cursors einen "update table where current of cursor" durchführen. Der sperrt so lange, wie kein Commit gemacht wird, wenn *CHG verwendet wird.
Dafür ist es natüürlich wichtig, dass dein Sperrprogramm in einer benannten ACTGRP läuft sonst hebt irgendein Commit im Job deine Sperre auf.

[BenderD]

Du kannst ja nach dem Fetch des For-Update-Cursors einen "update table where current of cursor" durchführen. Der sperrt so lange, wie kein Commit gemacht wird, wenn *CHG verwendet wird.
Dafür ist es natüürlich wichtig, dass dein Sperrprogramm in einer benannten ACTGRP läuft sonst hebt irgendein Commit im Job deine Sperre auf.

... unter commit kriegst du eine ausreichende Sperre erst mit dem update. Bei change sperrt der read überhaupt nicht. Ohne commit sperrt der for update cursor schon beim read, welche Sperre der genau setzt, habe ich nicht parat - ich arbeite grundsätzlich immer mit commit, weil das Stand der Technik ist und damit erforderlich für Revisions sichere Programme.

D*B