UPDATE : Verbesserungen

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Kollege Berger hatte vor einer Weile gewisse Unerquicklichkeiten im Update-
> programm entdeckt.

... diese bestand(en) darin, dass Update die Satztabelle nicht (lange
genug)
freigibt, ein Bearbeiter also keine Moeglichkeit hat, die Bearbeitung
eines
Satzes zu beenden, wenn Update "auch will". (und die anderen Bearbeiter
haben auch keine Chance zu arbeiten).

Ausserdem erfolgte Neutest ganz ohne Pause, so dass eine umgeleitete
Bildschirmausgabe (Option -R?) auch grosse Dateisysteme innerhalb
weniger
Stunden zum Ueberlaufen bringen konnte (... SATZ nnn GESPERRT ...).

> Diese konnten nun nach laengerer Machbarkeitsstudie ausgemerzt werden.
> 
> A) Wenn UPDATE auf einen gesperrten Satz stoesst (d.h. der zu ersetzende in der
>    Datenbank wird momentan bearbeitet - oder ist gesperrt geblieben)
>    dann:
>    -- macht es 15 Versuche mit Wartezeit von 2 Sek. dazwischen

30 Sekunden ist wenig. Manche Bearbeitungen dauern viel viel laenger.

>    -- jedesmal wird vor dem Warten die TBL freigegeben, dann wieder gesperrt
>    -- ist der Satz noch immer nicht frei, wird er nicht gespeichert, sondern
>       eine Meldung  <nummer> was locked in die Datei UPRO geschrieben

Ich habe viele Anwendungen, in denen automatisierte Updates ablaufen,
und zwar viele davon. Ein intellektuelles Auswerten der upro-Dateien
auf nichtstattgefundenes Speichern ist nicht akzeptabel. Das Standard-
verhalten von UPDATE sollte m.E. unbedingt so bleiben, dass es 
tendenziell endlos auf entsperrte Datensaetze (oder - das ist ja
geblieben - eine entsperrte .TBL-Datei) wartet, nur eben intelligenter
als jetzt. Ein "Aufgeben" nach einer gewissen (grossen!) Zeit sollte
hoechstens ueber einen zusaetzlichen Schalter realisiert werden.


>    -- weiter geht's mit dem naechsten Satz

viele Gruesse
Thomas Berger