[Allegro] update.job + optsget.inc überarbeitet

[Thomas Berger]

Lieber Herr Eversberg,

>> darstellt. Eine dritte Moeglichkeit ist ein datensatzspezifischer
>> Versionszaehler, wo dann bei jeder Bearbeitung "eins drauf" gesetzt wird.
>>
> Das ist endlich mal ein nicht so hammerartiger Vorschlag
> (Vorschlaghammer) wie die checksum.
> Aber aufwandsmäßig fahren wir günstiger mit dem oben diskutierten Modell. Nur
> evtl. eben der Versionszähler statt sitzungsinterne Zähler,
> mal schauen.

Ich halte diesen Ansatz aus folgendem Grund fuer nicht verfolgenswert:

Es handelt sich bei den Datumsstempeln, Bearbeiterkennungen und
Versionszaehlern um Meta-Informationen zum Datensatz, von der
Bedeutung vergleichbar mit der internen Satznummer.

Sie sind aber bei allegro (abgesehen von der Satznummer) in ganz normalen
Datenfeldern untergebracht, d.h. Anwender oder Anwendungen koennen das
aendern. Das ist soweit unproblematisch, wenn dann ein "regulaerer"
Speichervorgang erfolgt, der alle diese Informationen ohnehin neu
bestimmt und im Datensatz unterbringt.

Diese automatische Stempelung laesst sich allerdings abschalten und
muss bei einem "Playback" oder dem Spiegeln von Datenbanken sogar
abgeschaltet bzw. anderswohin abgebogen werden, um einen "identischen"
frueheren / fremden Zustand zu restituieren. D.h. gerade in Update-
freudigen Datenbanken kann immer auch noch ein Akteur unterwegs sein,
der mit einer alternativen Datumsstempel-Kategorie arbeitet bzw. der
"manipulierte" Inhalte in die Kategorie leitet, die von anderen
Prozessen fuer "den" Datumsstempel gehalten wird. Anreichern der
Datumsstempel um Versionsierungsinformation kann da ganz prinzipiell
nichts an der Konflikterkennung verbessern.

[Das war jetzt nicht fingiert: In HANS haben Normdatensaetze *drei*
Paare von Zeitstempeln:
1. Erste/letzte Bearbeitung in der Normdatei (aus den MAB-Feldern)
2. Erster/letzter Import in diese Datenbank (kn/ke-Parameter in der
   nur fuer das Normdaten-Update genutzten .CFG)
3. Erste/letzte Bearbeitung *in* dieser Datenbank (normale Zeitstempel)

Das liesse sich mit einigem Aufwand vermutlich retten (im PV-Abschnitt
und/oder Update-GM noch elaboriertes Umkopieren von Zeitstempeln
implementieren), aber im Allgemeinen Fall gibt es so lange keine
Funktionssicherheit, wie ueberhaupt noch etwas konfigurierbar ist: Mit
einer Schema-unabhaengigen Zeitkategorie, die weder abschalt- noch
bearbeitbar ist, saehe das anders aus, so ist allegro aber nicht.
]

viele Gruesse
Thomas Berger