Frage zur Commitmentsteuerung

[Fuerchau]

Satzzeiger-Probleme betreffen ausschliesslich aufgezeichnete PF's, LF's !

Noch was:
Solange kein Commit erfolgt ist, ist JEDER geänderte oder eingefügte Satz für andere Job's gegen Veränderung GESPERRT ! Gelesen werden kann er aber trotzdem (mit ggf. ungeahnten Konsequenzen).

Commit-Level:
*CHG: nur veränderte Daten sind gesperrt
*CS: auch eine aktuell gelesener Satz wird gesperrt und zwar auch dann wenn man READ(N) bzw. CHAIN(N) verwendet !
*ALL: alle zugegriffene Sätze, also auch nur gelesene, bleiben bis zum Commit gesperrt

Man sollte auch bedenken, dass sog. offene Commit's (also gesperrte Daten) nicht durch den Bediener-Dialog verängert werden (Kaffee-Problematik) !

[Fuerchau]

@kuempi

Die ganz vorsichtigen, die dann aber auch nix verstanden haben.
Dann kann ich mir das Commit auch sparen, da die Aufzeichnung ja bereits reicht.

[JonnyRico]

Hi ihr beiden,

danke für die aufklärenden Worte. Mensch da hat sich das zur Arbeit kommen heut morgen doch schon wieder richtig gelohnt.
Danke nochmals

Gruß

Sascha

[BenderD]

Hallo,

das mit dem automatischen Rollback von offenen Transaktionen ist ja gerade der Clou an der Commit Steuerung. Egal was immer passieren mag, es bleiben keine inkompletten Transaktionen in der Datenbank drin.

@Baldur:
Zum überlesen gesperrter Sätze, die sich in einer Transaktion befinden ist die Sperrstufe commited read vorgesehen.

Die Kaffepausen Problematik ist gerade mit Commit einfach und sicher zu lösen: Commit (oder gegebenen Falls ROLLBACK) vor jedem EXFMT oder anderem READ auf einen Bildschirm.

mfg

Dieter Bender

Satzzeiger-Probleme betreffen ausschliesslich aufgezeichnete PF's, LF's !

Noch was:
Solange kein Commit erfolgt ist, ist JEDER geänderte oder eingefügte Satz für andere Job's gegen Veränderung GESPERRT ! Gelesen werden kann er aber trotzdem (mit ggf. ungeahnten Konsequenzen).

Commit-Level:
*CHG: nur veränderte Daten sind gesperrt
*CS: auch eine aktuell gelesener Satz wird gesperrt und zwar auch dann wenn man READ(N) bzw. CHAIN(N) verwendet !
*ALL: alle zugegriffene Sätze, also auch nur gelesene, bleiben bis zum Commit gesperrt

Man sollte auch bedenken, dass sog. offene Commit's (also gesperrte Daten) nicht durch den Bediener-Dialog verängert werden (Kaffee-Problematik) !

[Fuerchau]

@Dieter

Leider gibts da zwischen LowLevel-Commit (RPG) und SQL einen kleinen Unterschied.
Im STRCMTCTL kann ich dies nicht angeben, so dass RecordlevelAccess grundsätzlich "schmutzige" Daten lesen kann.
Im SQL kann ich per "set option commit=*rr" das so angeben, dass ich keine Schmutzdaten bekomme.

Und was die Kaffeepause angeht, so ist das zwar mit dem Commit/Rollback klar, aber das Design der Anwendung muss passen, sonst committe ich eben doch unvollständige Daten.
Bisherige Anwendungen erlauben auch eine Kaffeepause, da sie häufig eigene Sperr-/Recovery-Methoden entwickelt haben.
Unter Commit sieht die Welt leider häufig anders aus, insbesonders wenn gemeinsame Daten (Stammdaten) geändert werden.

Nicht umsonst hat sich SAP dieser Problematik mit dem BatchInput elegant aus der Affäre gezogen.

[BenderD]

@Baldur: read committed ist das was as400 auch *CS nennt und das geht bei STRCMTCTL - was dann mit Rekord Löffel Ekzem passiert habe ich nicht verifiziert. (RR ist der mit den Lesesperren)

Nochmal zur Kaffeepause: wer da Dummfug programmiert, dem ist nicht zu helfen. alles was da ohne Commit drumherum gefummelt worden ist, geht mit Commit haar genauso und ohne Commit werden ohnehin unvollstäändige Transaktionen festgeschrieben, da wird mit einem kleinen Commit vor dem EXFMT nix schlechter - und man kann keine Sperre vergessen.

mfg

Dieter

@Dieter

Leider gibts da zwischen LowLevel-Commit (RPG) und SQL einen kleinen Unterschied.
Im STRCMTCTL kann ich dies nicht angeben, so dass RecordlevelAccess grundsätzlich "schmutzige" Daten lesen kann.
Im SQL kann ich per "set option commit=*rr" das so angeben, dass ich keine Schmutzdaten bekomme.

Und was die Kaffeepause angeht, so ist das zwar mit dem Commit/Rollback klar, aber das Design der Anwendung muss passen, sonst committe ich eben doch unvollständige Daten.
Bisherige Anwendungen erlauben auch eine Kaffeepause, da sie häufig eigene Sperr-/Recovery-Methoden entwickelt haben.
Unter Commit sieht die Welt leider häufig anders aus, insbesonders wenn gemeinsame Daten (Stammdaten) geändert werden.

Nicht umsonst hat sich SAP dieser Problematik mit dem BatchInput elegant aus der Affäre gezogen.