[Allegro] o-invent.flx

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> mit der neueren Möglichkeit der automatischen Nummernvergabe hatte ich
>> mich gefreut die Generatoren ablösen zu können und die Möglichkeit
>> gesehen, dass jetzt auch z.B. mehrere Mitarbeiter gleichzeitig
>> inventarisieren können. Leider haben wir uns dann Ende des Jahres doch
>> diverse doppelte Zugangsnummern eingehandelt. Das Problem scheint mir
>> folgendes zu sein: (hier ein kleiner Ausschnitt aus meinem o-invent.flx)
>>
> Das Problem liegt hierin:
> Ihre Variante von o-invent.flx vergibt die neue Nummer, bevor das
> Formular geöffnet und der Exp.Satz darin bearbeitet wird. Da kann
> der Nutzer sich Zeit nehmen - währenddessen kann jemand anders dieselbe
> Nummer vergeben, weil die neue ja noch nicht im Index steht.
> Das Numerieren darf daher erst dann erfolgen, wenn das Formular
> geschlossen ist und der Nutzer entschieden hat, das Ex. speichern
> zu lassen.

Hm. Das von Frau Panski gestern gezeigte Beispiel sieht aber
sauber aus:

set tbl loc
perform nextnum
...
put free


Auf den dritten Blick sehe ich aber den Knackpunkt: die ermittelte
Nummer geht in die Variable $Zug und nicht in den Datensatz, der
damit quasi umsonst gespeichert wird. Weil "nextnum" so bedient
wurde, dass Indexeintraege konsultiert werden (und eben kein
Generatorsatz aktualisiert wird), gibt es die geschilderten Effekte.

OOOOPS:

Ich stelle gerade fest, dass ich nicht aufgepasst habe: Es gab
frueher Generartorsaetze, und die Dokumentation spricht auch jetzt
noch von Generatorsaetzen, aber es sind gar keine Generatordatensaetze
mehr, zumindest nicht im frueheren Sinn: Die Saetze - so wie
von nextnum.flx behandelt/benutzt - enthalten nicht mehr die konkrete
letzte oder naechste Numer, sondern nur einen Pointer auf einen
zu konsultierenden Indexabschnitt, der dann ausgewertet oder
hochgezaehlt werden muss. Damit sind nun alle vergebenen Nummern
den folgenden beliebten und von der #00-Vergabe seit langem
bekannten Problemen mit klemmenden Nummerngeneratoren unterworfen:

- - Schmutz im Index:
0001
0002
001x

fuehrt dazu, dass nun ewig "0002" als naechste Nummer vergeben
werden wird.

- - "Schnelle" Loeschungen:
Wird ein Satz nach Nummernvergabe geloescht (bzw. die Nummer dort
ausgetragen), bekommt der naechste Vorgang u.U. dieselbe Nummer
wie der vorige. Das kann sehr problematisch werden, wenn die
urspruenglich vergebene Nummer trotz Loeschung in dieser konkreten
Datenbank dennoch als "gueltig" angesehen wird (traditionell gibt
es manchmal ziemlich wirre Geschaeftsgaenge die staendiges "Verschieben"
von Datensaetzen von einer Datenbank in die andere involvieren).
[Das ist wie mit dem "Generatorsatz": Gestern war die Bedeutung X,
heute ist sie Y, die identifizierende Zeichenkette "Generatorsatz"
wird fuer beides benutzt, wofuer, ist nur aus dem Zeitpunkt der Nutzung
klar. Ausserhalb des geschlossenen Systems der allegro-Dokumentation
(z.B. im Bereich dessen, was /ich/ zu wissen glaube) jedoch waere
der Bedeutungswandel nur anhand einer Aenderung des Identifikators
"Generatorsatz" erkennbar gewesen. Weil das nicht geschehen ist,
vermischen sich die Konzepte...]


M.E. sollte daher auch a99 "traditionelle" Nummerngeneratoren
unterstuetzen, die eine in einem separaten Datensatz gespeicherte Zahl
simpel hochzaehlen.

viele Gruesse
Thomas Berger




:zugang
  Zugangsnummernvergabe (fr KG angepasst bis einschl. put free)
#uoR |9
#uoP Z2008/
#uoF
set tbl loc           // .TBL blockieren, damit keiner speichern kann
perf nextnum          // ermittelt die Nummer, liefert sie in #uoY
if ="-1" jump fehler  // Nummernermittlung nicht gelungen
z=6                   // das sind die 6 Stellen hinter dem /
var #uoY JL0
ins #uoY
var "2008/" #uoY
ins $Zug
put free        // Satz speichern, zugl. TBL freigeben (erst ab V25.9)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSYv6imITJZieluOzAQJI7QP7BQBJIKMXGK68SG9zAiI98Aq1S1lPfhwy
/dV1t5wvPX7i/ivRtsOKUAmoOHtHcfurW4HXFwr3t1HQ4ozHKLs6PU1mcgI6UmUg
oQtGyZQbwi8nuyW4Ot7oFVP4kTUGOjHv+0uhtxV7dPWAbsMkGTyihu4ktey6+ASW
K0lbKM+eJ3Y=
=8Q17
-----END PGP SIGNATURE-----