SQL MassenUpdate und Sperre

[dibe]

Die Sperre nicht, aber das 'durchtikkern' des Satzes vom Anwender.
Wenn die den Satz zum Ändern anwählen, ändern sie (i.d.R) auch.
Fürs Ansehen gib es eine andere Option, die sperrt auch nicht.

[BenderD]

Die Sperre nicht, aber das 'durchtikkern' des Satzes vom Anwender.
Wenn die den Satz zum Ändern anwählen, ändern sie (i.d.R) auch.
Fürs Ansehen gib es eine andere Option, die sperrt auch nicht.

... mit dem Prinzip Hoffnung kommt man in der DV nicht weit.

[Fuerchau]

Nun, es war eigentlich schon immer so, dass Satzsperren nie erhalten bleiben, wenn eine Usereingabe erwartet wird. Dies führt auch gerne bei anderen Programmen dann zu Problemen.
Wenn man im Änderungsdienst verhindern will, dass jemand anderes dies parallel tun kann, nutzt man einen allgemeinen BelegLock-Service.
Dieser erstellt einen logischen Lock in einer Hilfsdatei, die dann immer geprüft wird bevor eine Belegbearbeitung startet. Wenn die Jobinformation mit gespeichert ist, kann man per API, jetzt auch via SQL, prüfen ob der Job noch lebt.

Die andere Methode ist eben:
- Satz ohne Sperre lesen und in einer Variablen merken.
- User führt die Aktion durch.
- Satz nun mit Sperre lesen und mit gespeicherten Infos vergleichen.
- Wenn gleich, weiterarbeiten, Updaten und committen.
- Wenn nicht, rollback und Hinweis, dass die Datengrundlage sich inzwischen geändert hat.

Sicherlich ist diese aufwändiger, aber erheblich stabiler und sicherer.
Diese Methode ist i.Ü. in der .Net-Welt bei der Verarbeitung von Datentabellen standard.

[E305GL]

Nun, es war eigentlich schon immer so, dass Satzsperren nie erhalten bleiben, wenn eine Usereingabe erwartet wird. Dies führt auch gerne bei anderen Programmen dann zu Problemen.
Wenn man im Änderungsdienst verhindern will, dass jemand anderes dies parallel tun kann, nutzt man einen allgemeinen BelegLock-Service.
Dieser erstellt einen logischen Lock in einer Hilfsdatei, die dann immer geprüft wird bevor eine Belegbearbeitung startet. Wenn die Jobinformation mit gespeichert ist, kann man per API, jetzt auch via SQL, prüfen ob der Job noch lebt.

Die andere Methode ist eben:
- Satz ohne Sperre lesen und in einer Variablen merken.
- User führt die Aktion durch.
- Satz nun mit Sperre lesen und mit gespeicherten Infos vergleichen.
- Wenn gleich, weiterarbeiten, Updaten und committen.
- Wenn nicht, rollback und Hinweis, dass die Datengrundlage sich inzwischen geändert hat.

Sicherlich ist diese aufwändiger, aber erheblich stabiler und sicherer.
Diese Methode ist i.Ü. in der .Net-Welt bei der Verarbeitung von Datentabellen standard.

..gut gut Deine Argumente "Methode/Aufwendigkeit" sind stimmig. Die wenigsten wissen dass es unter auch OS400-native ein Produkt gibt das diese Sperrprobleamtik, primär durch interaktive Programme ausgelöst, automatisch handelt einhergehend mit entsprechenden Ursachenmeldungen. Ein einfaches JA/NEIN Flag macht's möglich.