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

[Thomas Berger]

Lieber Herr Eversberg,

hier die gewuenschten Zitate:

>> Irgendwo?
>> Das können wir vorläufig nicht realisieren. Im Rahmem von OpenSource
>> könnte sich ggfls. jemand anders mal darüber hermachen. Es erfordert
>> Eingriffe, die dann ein Umformatieren aller Datenbanken erzwängen!
> 
> Nanu, neulich schrieben Sie, dass der gelesene Aenderungsstempel
> separat, quasi in "Metadaten" zum Datensatz hinterlegt wird (es
> ging ja darum, dass der auch im Satz veraendert werden kann, bevor
> es zum zurueckspeichern kommt). Oder bezog sich das auf eine in
> acon hinterlegte interne Kopie des "Originalsatzes beim Einlesen"?

Aus
< http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2011-October/034152.html >:

>>>
Das Änderungsdatum aus dem Satz wird im Satzobjekt (record.hpp
in den Quelldateien) in einem eigenen Feld (Eigenschaft) festgehalten,
[...]
<<<


Ob Sie nun 18 Bytes fuer den extra-Vermerk eines Zeitstempels
bereithalten oder eine vergleichbare Speichergroesse fuer eine
512- oder 1024-bit Checksum, scheint mir nicht wirklich ein Unterschied.

Ich *glaube*, einige Algorithmen zur Checksum-Bildung sind hinreichend
schnell, um auch den Live-Einsatz waehrend der kostbaren Zeit der
Datenbanksperre zu rechtfertigen.

[Fuer die Konflikterkennung ist es m.E. auch tolerabel, dass nicht
jede Bearbeitung erkannt wird, sondern nur solche, die den Datensatz
tatsaechlich gaendert haben ("weit" auseinanderliegende Bearbeitungen
fallen immer darunter, weil sich der Zeitstempel dann mindestens um eine
Sekunde geaendert hat).]




>>>> (Übrigens führt acon keine Liste der während des Jobs gesperrten
>>>> Sätze, um diese am Ende wieder freizugeben, falls noch nicht
>>>> geschehen.)
>>>
>>> aber warum hiess es dann, man koenne keine sitzungsuebergreifenden
>>> Datensatzsperren "mit avanti" realisieren, oder erinnere ich mich
>>> da ganz falsch?
>>>
>> Wo stand das?
> 
> Ich mache mich mal auf die Suche.

Hier:
< http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/1998-July/005656.html >

>>>
Es ist richtig, dass "get edit" nur innerhalb eines Auftrags sperrt. Am Ende
erfolgt automatisch eine Freigabe, um keine dauerhaft gesperrten Saetze in der
Datenbank anzusammeln.
<<<

Dagegen allerdings die Dokumentation in xget.rtf zu "get edit":

>>>
(Freigabe erfolgt beim Speichern oder Laden des nächsten Satzes).
<<<

Da es seit einiger Zeit zwei Satz-Objekte gibt, stellt sich allerdings die
Frage, was genau mit "Laden des naechsten Satzes" gemeint ist.

viele Gruesse
Thomas Berger