[Allegro] V32.4 und Indexparameteraufruf

[Thomas Berger]

Lieber Herr Eversberg,

xset.rtf dokumentiert dieses ungute Verhalten, ausserdem stolpere
ich ueber "... in avanti ebenfalls automatisch": Gibt es noch
einen Fall automatischer Sperre (abgesehen von PRESTO)?

Die numerischen Fehlercodes / Werte des CString sL finde
ich im Prinzip ganz brauchbar, wenn sie bei jedem Lesen
eines Datensatzes aufgefrischt werden, allerdings verstehe
ich das Muster von Werten und Vorzeichen ueberhaupt nicht,
eigentlich wuerde man ja "Flags" im Sinne von gesetzten
Bits erwarten und u.U. differenzieren negative Werte
verschiedene Abstufungen von "ok" und positive Werte stets
einen Fehler / Ausnahmebedingung.

0 - ist stets "o.k."

Zusatzinfo bei o.k.:
eigentlich nichts

Fehler:
diverse TBL-Fehler (oeffnen, nicht vhd. Satznummer, Schreibschutz)
diverse ALD-Fehler (oeffnen, keine Daten, Schreibschutz)
Inkonsistenz (falsche Satznr. am Satzbeginn in .ald-Datei)
Satz geloescht / Satznr. nicht belegt
Regulaeres Problem beim internen .tbl-Lock: Db bereits gesperrt
Fatales Problem beim internen .tbl-Unlock: Db bereits freigegeben
Regulaeres Problem bei Lock: Satz ist bereits gesperrt
Fatales Problem bei Unlock: Satz war nicht gesperrt


viele Gruesse
Thomas Berger


Am 18.05.2012 10:26, schrieb Fischer, Thomas:
> Hallo Herr Eversberg!
> 
>> Also Sie meinen, es müsse eine Möglichkeit geben, die 
>> prophylaktische Errechnung der Schlüssel beim Einlesen zu 
>> unterbinden, wenn man gar nicht vorhat, den Satz dann zu 
>> bearbeiten und wieder zu speichern?
>> Das ist noch nicht so gegeben, darüber ließe sich aber reden.
> 
> Ich versuche  mal zu erinnern:
> 
>> -----Ursprüngliche Nachricht-----
>> Von: allegro-bounces at biblio.tu-bs.de 
>> [mailto:allegro-bounces at biblio.tu-bs.de] Im Auftrag von 
>> Bernhard Eversberg
>> Gesendet: Mittwoch, 2. Mai 2012 12:43
>> An: Allegro-C Diskussionsliste
>> Betreff: Re: [Allegro] Mysteriöse Variable
>> Am 02.05.2012 12:28, schrieb Fischer, Thomas:
>>>
>>> Das heißt, dass bei einem find-Befehl mit etlichen hundert Treffern 
>>> für jeden Datensatz zusätzlich die Indexparameterdatei durchlaufen 
>>> wird, obwohl überhaupt nichts geändert werden soll?
>> Nur für den ersten und dann für jeden weiteren, sobald er 
>> durch "next" 
>> o.a. geladen wird. Nicht sämtliche Sätze schon sofort nach dem "find".
>>
>>>> Abhilfe brächte nur, weil wir auf die genannte 
>> Funktionsweise nicht 
>>>> leichterdings wieder verzichten können, ein separater, anders 
>>>> heißender "find"-Befehl, der das besagte 
>> Schlüsselberechnen dann eben 
>>>> nicht durchführte.
>>>
>>> Da die neue Methode die vorherige teilweise völlig über den Haufen 
>>> wirft (alle möglichen Variablen können auftauchen, die vorher nicht 
>>> oder anders besetzt waren),
>> Das scheint mir stark übertrieben.
>>
>>> wäre ich für einen anderen find-Befehl, wenn die Berechnungen 
>>> *durchgeführt* werden.
>> Hören wir mal zuerst, was Berger dazu sagt.
> 
> Der sagt:
> 
>> Von: allegro-bounces at biblio.tu-bs.de 
>> [mailto:allegro-bounces at biblio.tu-bs.de] Im Auftrag von Thomas Berger
>> Gesendet: Donnerstag, 3. Mai 2012 09:36
>> An: Allegro-C Diskussionsliste
>> Betreff: Re: [Allegro] Mysteriöse Variable
>>
>> Lieber Herr Eversberg,
>>
>>> Ja. Der Weg scheint mir zu sein, einen neuen set-Befehl zu machen, 
>>> natürlich nur für acon:
>>>
>>> set keymode on/off   [default on]
>>>
>>> wobei dann "off" den Zustand herstellen würde, daß beim Holen eines 
>>> Satzes die Indexparameter NICHT abgearbeitet werden, aber 
>>> normalerweise würde das eben geschehen, um automatisch für 
>> ein "put" 
>>> gerüstet zu sein, d.h. dafür kein "set lock" geben zu 
>> müssen, mit all 
>>> den von Berger beschworenen Imponderabilien.
>>> Es könnte nunmehr Dissens anheben, ob es nicht andersrum 
>> sein sollte...
>>
>> Ich glaube, da gibt es keinen Dissens: Es gibt einfach keinen 
>> Bedarf fuer das von Ihnen vorgeschlagene Standardverhalten, 
>> es schadet nur (die vorbeugende Schluesselberechnung ist 
>> Unfug aber selbst die Datensatzsperre ist fuer 99,99% aller 
>> Vorgaenge Overkill: In typischen Anwendungen werden staendig 
>> grosse Ergebnismengen zur Anzeige gebracht, in wenigen 
>> Anwendungen wird ab und zu ein einzelner Datensatz gespeichert).
>>
>> Es gibt auch keinen Grund, diesen Schalter ueberhaupt einzufuehren:
>> Wen ein Job "get edit" benoetigt, muss er eben "get edit" 
>> setzen. Und wenn er (nicht update.job, sondern etwas 
>> selbstgeschriebenes, das z.B. selbsermittelte Ergebnismengen 
>> manipuliert) noch weitergehende Sperren benoetigt, muss 
>> dafuer ein geeigneter Mechanismus her (ich gehe mal davon 
>> aus, dass nach einem selbstgesetztem "set tbl lock"
>> auch meine Schreibvorgaenge abgeschmettert werden) 
> 
> Mit freundlichen Grüßen
> Thomas Fischer  _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro
>