Wissensfrage READPE und gesperrte Sätze

[Fuerchau]

Es ist soweit richtig erkannt, dass ich natürlich mit READE(N)/READPE(N) arbeiten muss wenn ich gesperrte Sätze, die für mich nicht relevant sind, überlesen muss.
Bei SQL ist das halt so gelöst, dass ich (bis auf Ausnahmen) beim Select nie sperren kann.
Die Ausnahmen sind entsprechender Sperr-Level in der Commit-Definition oder "... for update ..." im Cursor. Aber auch genau dann habe ich das Problem, gesperrte Daten zu überlesen.

Konzeptionell sollte man das aber eigentlich über eine View (LF) lösen, die zu überlesende Daten direkt ausschließt. Somit stellt sich die Satzsperre nicht mehr als Problem dar und performanter ist es auch noch.

Ansonsten: READE/READPE wird wohl eher von der RPG-Runtime ausgeführt als von der DB-Ebene.
Zum Vergleich: COBOL kennt solche Befehle überhaupt nicht.

[Pikachu]

User 1 legt die Kiste 1 an. Wir halten diese gesperrt und zwar tatsächlich. ...

Warum ???

[harkne]

@DieterSchröter,

danke erstmal für das Problemverständnis. Ist anscheinend noch nicht überall angekommen. Genau so machen wir das im Moment auch. Ich dachte nur es gäbe vielleicht eine andere Lösung. Vielen Dank für die ausführliche Antwort

@Fuerchau
Ich will den Satz doch gar nicht lesen und schon gar nicht sperren. Das System liest den intern und trifft auf einen gesperrten Satz und lockt somit. Er hat aber an dieser Stelle gar nicht zu locken. Außerdem verwende ich eine LF, die ist nach Case ID geschlüsselt und ich mach einen READE mit Case-Id 3. Er will intern aber Case-ID 2 sperren weil er beim reade über ID3 raus liest zum vergleich. Er hat an dieser Stelle wie Dieter bereits geschrieben hat aber eigentlich nicht zu sperren weil ich den Satz gar nicht lesen will.

@Pikachu
Kann ich leider nicht mehr sagen. Ist auch nicht von mir. Ich habe nur mitbekommen dass hier über mehrere Programme hinweg gearbeitet wird und dies nicht anders ging. ***Hüstel*** Ich weiß. Das Ding fass ich aber nicht an ;-)

[Fuerchau]

Die Datei ist für Update geöffnet.
Wenn du also einen READE ohne (N) kodierst wird der gelesene Satz immer gesperrt (was soll das System denn auch anderes tun) und prüft nun die Schlüssel.
(Von deiner Sortierung ist das dann ja wohl absteigend;-).)
Wenn du statt READE selber einen READ und anschließenden IF für die Schlüssel machst hast du doch genau dasselbe Problem.

[harkne]

Wenn ich das so programmiere ist das genauso schlecht wie das System das jetzt macht. Ich hätte erwartet dass er intern einen READE(N) macht, vergleicht und dann erst den Lock macht.. Wenn man ein klein wenig Hirnschmalz reinsteckt dann könnte man "INTERN" hergehen und das genau so machen wie heute und wenn man feststellt, dass ein Satz einen Lock hat den selben Satz mit (N) lesen und dann prüfen ob er überhaupt zu der Gruppe die gelesen werden soll passt.

Allerdings habe ich ja schon von Anfang an akzeptiert dass die Dinge sind wie sie sind. Ich wollte nur wissen ob es noch andere Lösungen gibt, die diese Problematik vielleicht selbstständig löst.

[Fuerchau]

Die Lösung heißt eigentlich SQL.
Da der Select nicht automatisch sperrt hast du das Problem erst gar nicht.