[Allegro] Vb.246: V32.4 ist da (jetzt aber wirklich)

[Sibylle Koczian]

Lieber Herr Eversberg, liebe Liste,

Am 04.06.2012 07:36, schrieb Bernhard Eversberg:
> Am 01.06.2012 16:29, schrieb Sibylle Koczian:
>>
>> Die Beschreibung bei "NORMALERWEISE" verstehe ich so, dass hier "get
>> edit ..." nicht verwendet wird, sondern einfach "find", "first",
>> "next". Das wäre dann die Situation, in der nicht jeder Satz geändert
>> wird und ein prophylaktisches Berechnen der Registereinträge
>> unerwünscht wäre. Wenn man jetzt aber im Einzelfall doch geänderte
>> Sätze speichert, was ist denn dann mit den Registereinträgen?
>>
> Dann werden die nachträglich, kurz vor dem Speichern, ermittelt.
> Also nicht, wie bei "get edit..." schon prophylaktisch vor dem
> Bearbeiten.
> Und zwar geht das so:
> -- Befehl put kommt
> -- tbl wird gesperrt
> -- Satz wird gesperrt
> -- Zeitstempel wird geprüft: Ungleich -> Ende und Fehlermeldung
> "E: Sorry, rec ... was changed by somebody else"
> [update.job merkt das und protokolliert den Satz in "upro"]
> -- Schluessel des gespeicherten Satzes werden errechnet
> (Der ist ja dann unverändert gegenüber dem Zeitpunkt des Ladens
> VOR der Bearbeitung!) [Er wird in ein anderes Satzobjekt geladen,
> damit keine Interferenz mit dem bearbeiteten Satz entsteht]
> -- Schluessel werden verglichen mit dem Zustend im Arbeitsspeicher,
> also NACH der Bearbeitung, und entsprechend behandelt (gespeichert
> bzw. gelöscht in der Indexdatei)
> -- Satz wird geloggt
> -- Satz wird gespeichert, dabei freigegeben, TBL auch wieder freigegeben
>
Alles klar. Auf die Gefahr hin, dass Sie mir wieder mal meine 
Staatsangehörigkeit an den Kopf werfen: mit solchen Erklärungen arbeitet 
es sich doch sehr viel besser.

> Dann testen Sie jetzt lieber, bevor Sie sich voll auf unsere Aussagen
> verlassen! Vielleicht gibt's ja bei Ihren Daten und Prozeduren noch
> Dinge, die unserer Voraussicht entgangen sind. Sie müssen nicht
> befürchten, daß Datensätze verfälscht werden, sondern allerhöchstens,
> daß irgendwelche Schlüssel hinterher falsch sind oder fehlen. Unsere
> Tests waren in der Hinsicht alle sauber, sonst hätten wir nicht
> freigegeben. Aber wie gesagt, nach allem was wir schon erlebt haben ...
>

Werde ich tun. Kürzlich hatte ich merkwürdige Ergebnisse, allerdings 
tatsächlich mit den Daten selbst (es blieb eine Kategorie 
unerwünschterweise stehen), aber da fehlte mir die Zeit, genau 
nachzusehen. Wahrscheinlicher ist natürlich, dass ein Fehler im Job vorlag.

Beste Grüße,
Koczian