[Allegro] if diff und obj 2

[Thomas Berger]

Lieber Herr Eversberg,

>> das Objekt RECORD mit einem neuen Attribut zu versehen, das dann die bisherige
>> globale rst in a99 ablösen würde. Dann wären die beschriebenen Probleme
>> wahrscheinlich weg, ohne daß es Auswirkungen auf andere Funktionen hätte,
>> auch hinsichtlich avanti + acon.
>> Das Attribut ist eigentlich schon da, ...
> und zwar wo? (U.U. verstehen Sie da etwas miß.)

Gut dass Sie nachhaken: Ich meinte "rst", weil das dem "Rec" irgendwie
zugeordnet ist, wird etwa Rec auf Rec1 kopiert, dann auch rst nach rst1.
Ein erster Schritt sollte wirklich sein, das in das Objekt
hineinzuziehen, dann ist ja fuer den Bereich fast garantiert, dass keine
Inkonsistenzen auftreten.

Was es bedeuten mag, so ein "dirty"-Flag ueber laengere Zeit in den
sitzungsuebergreifenden Daten zu parken, ist mir momentan nicht klar.

Der eigentliche Spuk hingegen scheint mir von dem ebenfalls globalen
"chf" auszugehen, Bedeutung anscheinend "irgendetwas" ist gaendert.


>> Konkret scheint uebrigens die rein iV-bezogene Ersetzung
>>  insert _a_b_ zu "false positives" zu fuehren, jedenfalls macht
>>  jegliche Pfadnamennormalisierung var #ucc ins _\_/_ open file
>>  den aktuellen Satz "gelb".
> Dies entbehrt natürlich der Plausibilität, ein Nachvollzug gelingt
> mir jedoch nicht.

An einer HANS-Datenbank bringt folgendes test.flx:

var "lamp.hdt"
ins $hdtfile

var "/" $hdtfile
ins _\_/_
var (T"/" t".")
ins $logfile

show record
display

die Ampel bei vielen Saetzen auf "gelb". Und an der Demo-Datenbank
z.B. beim Satz

#00 321186885

nicht jedoch beim Satz

#00 811277

Subtil!



>> Der Anlass scheint mir guenstig, noch
>> ein lange vermisstes weiteres datensatzbezogenes Flag
>> einzufuehren: Habe /ich/ den fraglichen Satz (derzeit) selbst
>> gesperrt?
> 
> Das ist schwieriger, weil die Sequenz der Sätze im Offline-Speicher
> aus Effizienzgründen kein Array von RECORD-Objekten ist. In der Datei
> cat.$$$ stehen die Sätze, aber nur deren Texte, in cat.tab die Status-
> Attributwerte. Ein weiteres Flag hier unterzubringen ist nicht leicht,
> jedenfalls wäre da zunächst eine Machbarkeitsstudie nötig. Schau'mer mal.

"Effizient" wird es, wenn die Eintraege der .tab-Datei Vielfache
von 32bit lang sind. Ich wuerde vorschlagen, mindestens 32bit fuer
"Flags" zu reservieren und dann noch das, was an Satznummern und
Pointern etc. benoetigt wird: Denken Sie an das arme Betriebssystem,
das die scheinbar "oekonomischen" Bit-Tuefteleien auf Bytegrenzen
in seinen auf 32- oder 64-bit optimierten Buffern staendig neu
alignieren muss...

viele Gruesse
Thomas Berger