Fehlerbehandlung im RPGLE-FREE

[AG1965_2]

Das wäre aber ein Drama, wenn sich der Lesebefehl je nach Fehlerüberwachung anders verhielte!
Aber es passiert logischerweise das absolut Idente, der Lesebefehl kann nicht lesen. Ob man diesen Zustand nun per Bezugszahl, Built-In-Funktion oder MONITOR feststellt, darf für die Position des Dateizeigers keinen Unterschied machen.
Außerdem sollte man DB-Sätze nur dann sperren, wenn die Updatewahrscheinlichkeit hoch ist.
Zum Füllen eines Subfiles aber auf keinen Fall, wie Baldur schon völlig richtig angemerkt hat.
Und selbst wenn es ginge; die Faulheit beim Codieren würde sich da sowieso zur Laufzeit rächen. Man muss nur genug User drauf los lassen.

[camouflage]

Außerdem sollte man DB-Sätze nur dann sperren, wenn die Updatewahrscheinlichkeit hoch ist.
Und selbst wenn es ginge; die Faulheit beim Codieren würde sich da sowieso zur Laufzeit rächen. Man muss nur genug User drauf los lassen.

Genau aus diesem Grund verwende ich zum lesen eine logische Inputdatei und eine Updatedatei.
Und schon sind einige Probleme gelöst.

[AG1965_2]

Halte ich auch für übertrieben, nur deswegen 2 Datenpfade zu öffnen, wo es doch READ(N) usw. gibt, womit ich auch eine Datei, die für Update geöffnet wurde, ohne Sperre lesen kann.

[Fuerchau]

Die Satzwartezeit (Default 1 Minute) ist dann auch nicht zu verachten.
Warum soll man den User erst 1 Minute warten lassen um dann unvollständige Daten anzuzeigen?
Bei SQL und Transaktionen muss ja sowieso anders denken.

[B.Hauser]

Halte ich auch für übertrieben, nur deswegen 2 Datenpfade zu öffnen, wo es doch READ(N) usw. gibt, womit ich auch eine Datei, die für Update geöffnet wurde, ohne Sperre lesen kann.

Das klappt aber nur wenn Du ohne Commitment Control arbeitest.
Unter Commitment Control gibt weder die Erweiterung (N) noch der OpCode UNLOCK den Datensatz frei!

Birgitta

[AG1965_2]

Danke Birgitta, wieder was (von dir) gelernt!

[Fuerchau]

Dies gehört beim Einsatz von Commit/Control allerdings zum Grundwissen.
Vorsicht ist beim Commit-Level *ALL anzuwenden.
Jeder READ, also auch ein READ(N), bleibt bis zum Commit/Rollback gesperrt.
Ich habe noch keine Anwendung gefunden in der dieser Sperrstatus sinnvoll ist.

[BenderD]

Dies gehört beim Einsatz von Commit/Control allerdings zum Grundwissen.
Vorsicht ist beim Commit-Level *ALL anzuwenden.
Jeder READ, also auch ein READ(N), bleibt bis zum Commit/Rollback gesperrt.
Ich habe noch keine Anwendung gefunden in der dieser Sperrstatus sinnvoll ist.

Die dahinter stehende Anforderung ist völlig alltäglich und in vielen Anwednungen wird da ohne Commit aufwändig drumherumprogrammiert:
- bei der Bearbeitung eines Auftrages müssen der Kopf und alle Positionen gesperrt werden. Lösung mit Commit; Sperrstufe Repeatable read (AS400 nennt das *ALL). Work around: Sperrkenzeichen im Kopf, das aber einfach ignoriert werden könnte.
- Bei einer Lagerumbuchung müssen angezeigte Lagerbestände gesperrt sein. Lösung mit Commit: Repeatable read. Ohne Commit: hoffentlich klappt das jetzt.
BTW: die Ausgangsfrage wäre mit commit Level Read committed elementar lösbar gewesen, da werden gesperrte Sätze überlesen (bei read uncommited kriegt man alle gezeigt.

Ich kann nur immer wieder empfehlen sich mit Commit Steuerung vertraut zu machen, statt falsche Vorurteile abzulassen. Für Software Häuser ohnehin ein Muss (ich enpfehle einen Blick in das europäische Produkthaftungsrecht).

D*B

[kretzsch]

Für mein Verständnis sehr hilfreich, danke