UPDATE : Verbesserungen

[Thomas Berger]

Lieber Herr Eversberg,


> Noch einen Schalter? Das lassen wir lieber. Ich habe kurzerhand die Zeit auf
> 2 Stunden hochgesetzt (3.600 Versuche a 2 Sekunden). Es muss die Devise
> ausgegeben werden, dass keiner sich laenger als 120 Minuten an einem Datensatz
> festhalten darf! Was soll das denn sonst kosten...

Aber was wenn? Und es gibt ja auch Datensaetze, die nach 
irgendwelchen Crashs (oft unerkannt) gesperrt sind, ORDER-
Benutzer wissen ein Lied davon zu singen.

UPDATE hat Defizite, die von seiner Herkunft als Playback-
Tool herstammen, etwa dass die Angabe einer Dateinummer
nur bei Neusaetzen moeglich ist. Man muss aber dennoch damit
rechnen, dass ein Update nicht bis zum Ende durchlaeuft
(Stromausfall) und es neu gestartet werden muss (auch
auf die Gefahr hin, Dublette Neusaetze manuell eliminieren
zu muessen oder vorher - Graus! - ein Backup zurueckzuspielen).

Wenn nun aber Update in gewissen Situationen einzelne
Datensaetze ueberspringt, kann es zu noch unangenehmeren
Effekten kommen, wenn weiter hinten stehende Datensaetze
davon ausgehen, dass weiter vorne stehende Datensaetze
verarbeitet worden sind (man denke an Nachladeoperationen
im Bereich der Globalen Manipulation waehrend des Updates).

Ich finde immer noch, dass UPDATE sich bei gesperrten Saetzen
wie bei einer gesperrten .TBL-Datei verhalten sollte, also
moeglichst unendlich lange (und dabei ressourcenschonend) 
wartet. Mit Abstand zweitbeste Loesung waere, dass Update nur 
endlich lange wartet, dann aber die Verarbeitung komplett 
abbricht (natuerlich mit entsprechendem Errorlevel).
Die Maxime sollte stets sein, dass das Programm sich sklavisch
an die in der Update-Datei angegebene Verarbeitungsreihenfolge
zu halten hat, wenn das nicht geht, darf es auf keinen
Fall tricksen.

viele Gruesse
Thomas Berger