[Allegro] jenseits von offline

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

die Bemerkungen aus Berlin liessen mir keine Ruhe, und ich habe
mir die Nummerngenerierungen noch einmal genauer angesehen.

Zunaechst einmal ist seit den Beobachtungen von 2009
<
http://sunny5.biblio.etc.tu-bs.de/pipermail/allegro/2009-October/030232.html
> fast nichts passiert:

Es gibt nextnum.flx, dort aber, wo nextnum genutzt wird, gibt es
jeweils eine Privatimplementierung: o-rech.flx, o-invent.flx,
sowie z-nband.flx. Diese sind auf unterschiedlichem Stand, mal
sind die Generatoren fest verdrahtet, mal beruecksichtigen sie
nicht #9A$F. Einzig das "Testen" der Generatoren von order.rtf
bzw. o-funk.flx aus nutzt "den" nextnum.flx. Das heisst aber
natuerlich, dass anders getestet wird als im Echtbetrieb genutzt,
diesbezuegliche Irritationen sind aber nicht bekannt geworden.

Bestellnummerngeneratoren werden weiterhin angeboten, aber
nirgendwo genutzt, auch das hat sich nicht geaendert. Konsequenter-
weise gibt es auch keine Moeglichkeit, einen konkreten
Bestellnummerngenerator einzustellen oder auszuwaehlen (aber
auch der vorgegebene BSTD wird nicht genutzt).

Eine Sache hat sich allerdings im Mai 2014 geaendert: nextnum.flx
muss (zumindest beim ersten Mal, sofern noch nichts zwischengespeichert
wurde) den Generatorsatz aufsuchen um dessen Vorgaben aus #9A
auslesen zu koennen. Das geht mit f1nd, so dass eine eventuell
bestehende Ergebnismengen nicht weggedrueckt wird, aber natuerlich
ist der derzeit zu bearbeitende Datensatz dann nicht mehr der
aktive und muss nach Bestimmung der Nummer irgendwie zurueck-
geholt werden.

Bis 2014 passierte das durch Umschalten mittels "set obj 2" und
Zurueckschalten mit "set obj 1". Das ist etwas fummelig, man
darf irgendwie kein oder kaum mit "new 0" dieses Objekt "leeren",
denn sonst ist ploetzlich ein spaeter geladener Satz gelb.
Mit dem (ungefaehr mit V28 eingefuehrten) "erase main" kann man
das aber umschiffen (sofern einem ueberhaupt an Hygiene im obj 2
gelegen ist). Folgendes funktioniert etwa an der Demodatenbank
so, dass anschliessend nicht mehr Saetze gelb sind als vorher
und anschliessend auch derselbe Satz aktiv ist wie vorher:

set obj 2
erase main
disp\show rec\mess vor find
f1nd #138
disp\show rec\mess ok
erase main
set obj 1
disp\show rec

2014 dann wurde dies umgestellt, ich dachte zunaechst wegen a35, da
gibt es aber kein nextnum. Aber es waere von Vorteil, auch ohne
das obj 2 auszukommen. Was also aktuell passiert ist folgendes:

Eingangs wird die Satznummer gemerkt, sowie der komplette Inhalt
des Datensatzes:

var i
ins $n:oi
var kr
ins $rec

Zum Schluss wird dann resituiert mittels

var $n:oi
set recn
erase main
var $rec
ins

Dazu ist zu sagen:

* "set recn" gibt es nur fuer acon, nicht fuer a99.
  Gluecklicherweise, denn ich will ja nicht dem nachgeladenen
  Generator-Satz die interne Nummer eines ganz anderen Satzes
  verpassen.

* das Ueberschreiben des (gluecklicherweise des richtigen)
  Datensatzes mit $rec fuehrt im Fall eines bereits vorhandenen
  Datensatz (z.B. der Test-Situation aus dem Order-Menue, wo
  der zu testende Generatorsatz bereits geladen ist) dazu, dass
  dieser als Editiert gilt, obwohl keine Aenderung erfolgte.

Oft typisch ist allerdings die Situation, dass ein gerade angelegter
Datensatz vor dem ersten Speichern mit einer oder mehreren frisch
generierten Nummern auszustatten ist: Die interne Satznummer ist
dann 0, und blau plus gelb ist immer noch blau (zumindest bei
allegro...).

Eigentlich geht es ja nur um das "zurueckholen" des Satzes, den
man durch das vorangegangene "f1nd" aus dem Fokus verloren hat.
Ist also die gemerkte interne Satznummer ungleich 0, so genuegt
ein einfaches

var "#" $n:oi
f1nd

und er ist - inklusive aller angefallenen Aenderungen - wieder
da.

Ist es hingegen ein nicht abgespeicherter Neusatz, so muss er aus
dem Offline-Speicher herbeigeholt werden, z.B. mit

var $n:oi
if =0 last offline

Aaaber: Das funktioniert nur in den "typischen" Situationen, wo
der Ausgangs-Neusatz tatsaechlich gerade mit "new 0" angelegt
worden war. Denkbar sind aber auch Szenarien, wo eine Reihe
von ungespeicherten Neuaufnahmen zunaechst angelegt wird und
dann mit Nummern versehen und gespeichert wird.

Eine mir voellig in Vergessenheit geratene Funktionalitaet ist
dabei der Cstring "oq", der die Position eines Satzes in der
offline-Datei zurueckgibt. Und mit "get q ..." kann ich diesen
Satz dann spaeter selektieren (mal angenommen, dass zwischendurch
niemand den Besen geschwungen hat).

Es gibt da nur zwei Schwierigkeiten:

a) ein ganz frisch und bislang noch ohne jeglichen Inhalt angelegter
   Satz landet nicht in der Offline-Datei und kann auch nicht
   zurueckgeholt werden. Diese Fallunterscheidung (Satznummer 0 wg.
   Neusatz und kein Inhalt) muss also stets mitgefuehrt werden.

b) ein frisch angelegter und anschliessend /mit/ Inhalt versehener
   Satz landet *zu spaet* in der Offline-Datei:
   Man kann das an der Demo-Datenbank testen:
x new\#20 otto\var oq\mess
   liefert das Resultat 4262112 (Hexadezimal nicht ganz so krumm:
   0x068080). Klickt man auf "Daten in Bearbeitung", so ist das Fenster
   "Offline List" in dem Moment leer. Schliesst man es und oeffnet es
   sofort erneut, ist der Satz mit "#20 otto" ploetzlich da und
   "var oq" liefert das erwartete "1". Auch ein "f1nd" bringt den Satz
   in die Offline-Liste und verhilft ihm zu einem gesunden Wert von oq,
   das hilft aber nicht, schliesslich muss ich vor dem f1nd die
   Position ermitteln, um danach wieder zurueckzufinden...

   In a99.cpp ist das eigentlich angelegt, denn ich finde hier:

case 'o':  // o size of ext file / offline records queue
  if(tsk[i+1]=='q')  // oq : nr of curr rec in offline queue
  {
    if(nrec<1) { nrec=WriteRec(Rec); OnButtonUndo(); }  // online rec
ohne Aenderung	
    sprintf((char*)ftx+strlen(ftx),"%d%c",nrec,0);
    i+=2;
    break;
  }

Wenn ich es recht verstehe, ist WriteRec() die Funktion, die Saetze
in den Offline-Speicher zwingt, aber OnButtonUndo veraendert nrec
ebenfalls, insofern kann ich leider nicht herausfinden, ob nrec
unerwartet vorbesetzt ist oder das vorgebliche Undo hier hineinspukt.

Koennten Sie sich das einmal genauer ansehen?

viele Gruesse
Thomas Berger