[Allegro] acon + update.job neu bereitgestellt

[Bernhard Eversberg]

Am 27.04.2012 09:50, schrieb Thomas Berger:
> Lieber Herr Eversberg,
>
>
> "Im Feld" sind diverse Versionen von update.job, die nur mit acon
> bis etwa Januar 2012 funktionieren, und dann wird es neuere
> update.job geben, die nur mit zukuenftigen acons funktionieren.
>
> Ich halte die Gefahr fuer real, dass Anwender (nicht des GP, aber
> andere) in eine Situation mit neuem acon und altem Update.job kommen,
> oder sogar umgekehrt (einfacher Fall: Der neue Update.job muss die
> acon-Versionsnummer erfragen und sich weigern zu arbeiten, wenn die
> zu alt ist). Daher meine Fragen, ob aeltere Update.job (mit get edit
> und Expliziter Ansteuerung von #-#) mit neueren acons zusammenarbeiten
> werden koennen.
>
Das werden sie können.
In den neuen bauen wir also den Test ein, ob es sich um V32.4 oder
später handelt.

>
> O.k., also update.job. Ein "Vorab-Test" auf gesperrte Saetze macht
> wenig Sinn, allerdings sieht man hier deutlich, dass man einen
> definitiven Test ("get edit") bereits beim Einlesen des Satzes
> benoetigt, nicht erst beim "put".
>
Das seh ich gar nicht deutlich, erklären Sie es mal verständlicher.

>
>
>>> Hier schon oft angesprochen und begruendet: Das Standardverhalten sollte sein,
>>> dass update (nicht "put") es immer weiter versucht, auch auf die Gefahr des
>>> "Aufhaengens".
>>>
>> Darüber kann man nochmal reden, im update.job jedenfalls kommt "update"
>> nicht vor, nur "put".
>
> Sorry: Hier meinte ich genau wie Sie mit "update" die Steuerdatei
> "update.job"
>
Das seh ich anders. Wir reden über sehr seltene Fälle! Und auch bei
denen besteht dann keine Gefahr von Datenschäden, und darum geht's
doch primär.

>
> Wenn aber doch das Verwerfen des Satzes inakzeptabel ist, muesste
> ich an dieser Stelle den Originalzustand des Datensatzes aus der
> Update-Datei erneut herbeiholen und die gesamte Verarbeitung neu
> durchfuehren. Inklusive Korrektur aller Zaehler, damit ich nicht
> hinterher scheinbar einen Datensatz mehr bearbeitet habe als in
> der Datei vorkamen. Das wird ein enormer Aufwand fuer update.job
> (eine Art Rollback-Mechanismus), nur weil Sie denken, ohne
> "get edit" auskommen zu koennen.
>
Wie gesagt, SEHR seltene Fälle! Entweder wir lassen's erst mal
drauf ankommen oder bauen ein, wie bei UPDATE.EXE, daß dann
gewartet wird, bis der Admin was tut. Dann braucht er nicht
hinterher den enormen Aufwand zu treiben, den Sie befürchten,
aber er kommt u.U. morgens, und es sind 100.000 Sätze noch
nicht durch.

>
>
>
> Wenn sichergestellt ist, dass die Grundlagen fuer acon's put (neben
> der Version des Datensatzes aus der Update-Datei) die vom Benutzer
> abgespeicherte Version ist, ist das Problem auch nicht anders gelagert
> als eine Bearbeitung, die vor einer Stunde stattgefunden hat. Oder
> die in einer Stunde stattfinden wird.
>
Da versteh ich auch wieder nicht.

Im übrigen haben Sie Handlungsfreiheit, einen noch neueren, noch
besseren  update.job  auf der Grundlage des jetzt existierenden
acon zu machen.

B.E.