Transaktionssteuerung im RPG Programm

[BenderD]

Es wird alles per SQL gemacht und die Lib ist journalisiert. Ein Rollback funktioniert auch, nur der Status ist eben noch 1 nach dem Rollback.

Welche Parameter muss ich denn bei dem CRTSQLRPGI beachten?

Commit steht auf *NONE.

... was verstehst Du jetzt unter Status? Was zeigt WRKCMTDFN an?

D*B

[shuelzer]

Unter Status verstehe ich den "Status" der Transaktion, den ich mit get Diagnostics abfragen kann.

WRKCMTDFN zeigt eine offene Transaktion für den Job nach dem Commit.

[BenderD]

Unter Status verstehe ich den "Status" der Transaktion, den ich mit get Diagnostics abfragen kann.

WRKCMTDFN zeigt eine offene Transaktion für den Job nach dem Commit.

... was sagt denn der SQLCODE direkt nach jedem sql statement dem Commit? und wie sieht das bei WRKCMTDFN genau aus (dass da eine Commit Definition angezeigt wird ist so in Ordnung

D*B

[shuelzer]

... was sagt denn der SQLCODE direkt nach jedem sql statement dem Commit? und wie sieht das bei WRKCMTDFN genau aus (dass da eine Commit Definition angezeigt wird ist so in Ordnung

D*B

Ich weiss nicht genau welche Informationen Sie brauchen, aber der SQLCODE ist nach jedem Statement 0.

WKRCMTDFN zeigt eine neue Commit-Definition, ab dem Zeitpunkt des Ausführens von Set Isolation Level mit der Standardsperrstufe *CS.
Lokal anstehende Änderungen steht auf Nein vor dem Insert.
Nach dem Insert dann auf Ja und nach dem Commit wieder auf Nein. Die Commit-Definition bleibt bestehen.

Jetzt war die Idee, nach dem Commit oder Rollback mit Set Isolation no commit die Transaktion zu beenden. Funktioniert aber auch nicht.

Ein exec sql set option liefert ein SQL-Vorkompilierungsfehler.

Sry für die vielen Fragen. Wir sind noch neu in der Thematik Transaktionen auf System i und machen gerade unsere ersten Gehversuche.

[Fuerchau]

Embedded SQL startet (wenn nicht vorher manuell aufgerufen) automatisch STRCMTCTL.
Damit wird für die Aktivierungsgruppe eine Commitdefinition erstellt.
Diese wird erst nach Ende des letzten SQL-Programmes bzw. der Aktivierungsgruppe gelöscht.

Der Hinweis "nach dem Commit wieder auf Nein" besagt doch, dass die Transaktion erfolgreich abgeschlossen ist.

Was stört dich also das Bestehen der Commit-Definition ?

[shuelzer]

Umso länger ich drüber nachdenke habe ich kein echtes Problem.
Man muss nur einmal wissen, wie die As400 da tickt.

Ich hatte eine Funktion geschrieben openSqlTransaktion() die eine neue Transaktion starten sollte. Diese Funktion sollte eine Exception werfen, wenn ich mich bereits in einer Transaktion befinde. Andere Funktionen, wie z.B. anlegenArtikel() sollten diese dann verwenden. Wenn aber ab dem ersten Aufruf immer eine geöffnet ist, muss ich immer abfragen ob schon eine offen ist und daran teilnehmen. Um das mal vereinfacht auszudrücken.

Danke für die Unterstützung

[BenderD]

Ich weiss nicht genau welche Informationen Sie brauchen, aber der SQLCODE ist nach jedem Statement 0.

WKRCMTDFN zeigt eine neue Commit-Definition, ab dem Zeitpunkt des Ausführens von Set Isolation Level mit der Standardsperrstufe *CS.
Lokal anstehende Änderungen steht auf Nein vor dem Insert.
Nach dem Insert dann auf Ja und nach dem Commit wieder auf Nein. Die Commit-Definition bleibt bestehen.

Jetzt war die Idee, nach dem Commit oder Rollback mit Set Isolation no commit die Transaktion zu beenden. Funktioniert aber auch nicht.

Ein exec sql set option liefert ein SQL-Vorkompilierungsfehler.

Sry für die vielen Fragen. Wir sind noch neu in der Thematik Transaktionen auf System i und machen gerade unsere ersten Gehversuche.

...
- Die Commit Definition wird bei embedded SQL implizit gestartet und beendet sich bei Ende der ACTGRP automatisch (Vorsicht: RCLACTGRP hat default *normal)
- Transaktionen werden implizit gestartet mit der ersten Datenoperation unter commit.
- commit beendet die Transaktion und gibt alle Sperren frei
- rollback nimmt anstehende Änderungen zurück und beendet die Transaktion ebenfalls mit Freigabe der Sperren

mit anderen Worten: alles im grünen Bereich

D*B