[Allegro] if diff und obj 2

[Anando Eger]

Hallo Herr Berger,

danke für den Testfall! Hier haben sie wohl den offline-Speicher-Bug 
getroffen, dem ich schon jahrelang nachjage ... 

Nach einem frisch gestartetem a99 verhält sich der erste Lauf
Ihres Test anders als bei einem zweiten Start. (Meldungen
2a _und_ 2b erscheinen beim ersten Mal, ab dem zweiten Lauf
erscheint Meldung 2b nicht mehr)

Wenn man in Ihrem Beispiel vor dem Start des Test-Flexes den
offline-Speicher leert, passiert bei jedem Durchlauf das gleiche.
Der diff-Fehler scheint also davon abzuhängen, ob ein betroffener
Satz vorher schon im offline-Speicher war oder nicht.

Viele Grüße
Anando Eger


On 25 Apr 2013 at 0:52, Thomas Berger wrote:

> Lieber Herr Eversberg,
> 
> im Nachgang zu meinen "a99-Beobachtungen" von letzter Woche
> (Problem beim "set lock", falls ein Datensatz bearbeitet ist) bin
> ich auf ein weiteres Problem gestossen, "if diff" liefert ein falsches
> positives Ergebnis, bzw. manchmal ein korrektes negatives, das aber
> wohl auf einem Doppelfehler beruht...
> 
> Der folgende Flex kann auf der Demo-Datenbank angewandt werden,
> auch zwei- oder dreimal:
> 
> 
> set obj 1
> find #1
> if diff mess diff(1a)
> new 0
> #20 foo
> copy obj 1 2
> erase
> find #1
> if diff mess diff(1b)
> 
> set obj 2
> var "#" k_1
> ins ,foo,bar,
> mess
> ins
> 
> set obj 1
> if diff mess diff(2a)
> set obj 2
> set obj 1
> if diff mess diff(2b)
> find #1
> show record
> display
> if diff mess diff(3)
> 
> undo
> end
> 
> Was passiert, ist dass zunaechst ein Datensatz "eingestellt"
> wird und ueberprueft, dass der nicht EDT ist.
> 
> Dann wird intern ein neuer Datensatz angelegt, mit Kategorien
> geimpft, nach obj 2 kopiert und verworfen.
> 
> Dann wird "sicherheitshalber" wieder der Ursprungsdatensatz
> eingestellt (nach erase ist sonst oft die interne Satznummer
> 0 und alles wird unuebersichtlich: Indizes werden leer,
> Speichern beliebiger Saetze bringt "wrong database" etc.)
> 
> In obj 2 wird anschliessend eine Ersetzung durchgefuehrt.
> 
> Anschliessend wird auf obj 1 zurueckgeschaltet, un nun wird
> es interessant:
> 
> 1.) Der Satz ist angeblich veraendert ("diff(2a)")
> 
> 2.) nach einmal hin- und herwechseln ist er angeblich
>     nicht mehr veraendert (kein "diff(2b)")
> 
> 3.) Nach explizitem Neuladen entpuppt er sich wieder
>     als veraendert "diff(3)", konsequenterweise steht
>     er als EDT in der Offline-Liste, wenn man das
>     abschliessende undo deaktiviert
> 
> In dem Szenario, wofuer ich diese Konstruktion einsetze,
> ist leider weder "undo" noch "put" eine Option: Ich baue
> aus einer externen Datei einen Datensatz zusammen und
> manipuliere den, erst dann weiss ich, welcher Datensatz
> zu laden ist: Der wird dann anhand des Gebastelten
> manipuliert und gespeichert. Das "EDT" betrifft aber
> den Satz, der waehrend der Bastelaktion aktiv ist, das
> kann ein beliebiger sein, der evtl. geloescht oder
> tatsaechlich veraendert ist, jedenfalls will ich da keine
> Fakten schaffen (/und/ - das ist im Test nicht abgebildet,
> es erfolgen zwischendurch Umschaltungen auf obj 1, um
> Saetze zu laden und deren Primaerschluessel zu bestimmen).
> Als Abhilfe koennte ich natuerlich einen "eigenen" Datensatz
> neu erzeugen, speichern, und im folgenden als "Anker" nutzen,
> der muss dann allerdings "aufgeraeumt" werden, was wiederum
> die Mechanismen verkompliziert, die Aktion abbrechbar zu machen.
> 
> Ich kann leider anhand der Quellen (ist das neueste a99 wirklich
> vom November?) wenig erkennen, nur dass "set obj" den Offline-
> Speicher impft, wenn von 1 auf 2 geschaltet wird, nicht jedoch
> umgekehrt. Und dass da record-spezifische und ein globales
> Change-Flag im Spiel sind, die hier anscheinend irgendwo
> durcheinandergeraten.
> 
> viele Gruesse
> Thomas Berger
>