Exception Handling bei Satzsperre in SQLRPGLE

[B.Hauser]

@Baldur

Was ich mich allerdings frage, wieso der SELECT gesperrte Sätze nicht liest ?
Einen Fehler gibts eigentlich erst beim UPDATE/DELETE oder der gesperrte Satz wird einfach überlesen.

Wird ein Cursor definiert und ein Update oder Delete mit WHERE CURRENT OF, wird i.d.R. nur ein einziger ODP (open data path) verwendet. Damit muss die Sperre bereits beim Fetch und nicht erst beim Update erfolgen.

(... genau wie beim native I/O in Update Dateien)

Wird ein Cursor definiert und z.B. die relative Satz-Nr. oder der unique Key zurückgebracht und der anschließende Update entweder über die relative Satz-Nr. oder den unique Key gemacht, werden 2 ODPs generiert (und damit natürlich auch 2 FULL OPENS ausgeführt). In diesem Fall erfolgt die Satz-Sperre erst beim Update.

(... man liest mit native I/O die Input-Datei ein und macht den Update auf die (gleiche) Update-Datei)

Birgitta

[BenderD]

... das hat mit den ODPs allenfalls mittelbar zu tun, sondern hängt davon ab welche Art von Sperre angefordert wird und welche Art von Sperre der Satz gegenwärtig hat. Das kann unter commit alles ein wenig anders aussehen...


D*B

@Baldur


Wird ein Cursor definiert und ein Update oder Delete mit WHERE CURRENT OF, wird i.d.R. nur ein einziger ODP (open data path) verwendet. Damit muss die Sperre bereits beim Fetch und nicht erst beim Update erfolgen.

(... genau wie beim native I/O in Update Dateien)

Wird ein Cursor definiert und z.B. die relative Satz-Nr. oder der unique Key zurückgebracht und der anschließende Update entweder über die relative Satz-Nr. oder den unique Key gemacht, werden 2 ODPs generiert (und damit natürlich auch 2 FULL OPENS ausgeführt). In diesem Fall erfolgt die Satz-Sperre erst beim Update.

(... man liest mit native I/O die Input-Datei ein und macht den Update auf die (gleiche) Update-Datei)

Birgitta