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

[Bernhard Eversberg]

Am 17.01.2012 10:33, schrieb Thomas Berger:
>
>> Sicher, nur ist das ja hier nicht das eigentliche Problem, sondern die
>> Tatsache, daß der Satz inzwischen überhaupt von jemand gespeichert
>> wurde. Das läßt sich auch mit weniger Aufwand abtesten, man muß
>> nicht gleich zur ganz dicken Brechstange greifen. Wir könnten an den
>> Zeitstempel z.B. noch die interne Satznummer anhaengen und die laufende
>> Nummer des in der betr. Sitzung gespeicherten Satzes sowie den Operatorcode.
>
> Die interne Satznummer eines gegebenen Satzes duerfte sich selten aendern,
> der Operatorcode, sofern ueberhaupt gegeben, ebenfalls nicht (hochfrequente
> Bearbeitungen ein und desselben Satzes haben anzunehmenderweise haeufiger
> systematische Gruende).
>
> Die laufende Nummer des Satzes waere ein gewisser Schutz, muesste aber
> in der Datenbank hinterlegt werden.
Wieso das denn? Es geht um die laufende Nummer der Speicherung während
einer Sitzung oder eines Jobs! Um die sonst identischen Zeitstempel zu
differenzieren. Es geht zudem *nicht* darum, daß die #99e zweier
verschiedener Sätze unbedingt verschieden sein müßten -das müssen sie
nicht, denn sie werden nie verglichen! Verglichen werden nur die
Stempel eines im Arb.Speicher von acon oder a99 befindlichen Satzes mit
dem Stempel desselben Satzes, wie er im Moment des Speicherbefehls auf
der Platte steht. *NUR das* ist die Funktion der #99e.
Ihre weiteren Ausführungen lassen darauf schließen, daß Sie mit der
#99e noch andere Vorstellungen oder Absichten verbinden, die da nicht
mit verbunden sind.

B.E.