[Allegro] Die Tuecke des Objekts bei der Inventarisierung
Thomas Berger
ThB at Gymel.com
Di Okt 20 00:42:03 CEST 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lieber Herr Eversberg,
nummer.rtf erklaert so wortreich, warum eigene Generatorendatensaetze
zum Speichern hochzuzaehlender Nummern antiquiert und suboptimal sind,
und dass Mustervorgaben und Hochzaehlen anhand des Index viel sicherer
und effizienter sind, dass man gleich stutzig werden koennte.
Jedenfalls: Mit der gewaehlten Methode ist trotz Datenbanksperre die
eindeutige Vergabe von Zugangsnummern nicht gewaehrleistet:
o-invent.flx sieht als Standardvorgabe (der entsprechende Code ist
auskommentiert) vor, dass die generierte Zugangsnummer nicht in den
Titelsatz ueberfuehrt wird. Ausserdem wird das Speichern des
Exemplarsatzes mit der Zugangsnummer dem Benutzer anheim gestellt.
[D.h. es gibt den Fall, dass eine sinnlose Zugangsnummer generiert wird,
da sie weder im Titelsatz landet noch im ueberhaupt nicht angelegten
Exemplarsatz, diesen Fall meine ich aber nicht]
Wohl deswegen wird die Zugangsnummer "frueh" generiert, naemlich mit
dem initialen Bestellsatz als Ausgangssatz: Datenbank sperren,
Nummer generieren, Nummer im Bestellsatz hinterlegen, Bestellsatz
speichern und Datenbank gleichzeitig freigeben.
Dass die Zugangsnummer im Bestellsatz eher nichts zu suchen hat, weil
sie eben nicht in 1:1:-Relation zu Bestellsaetzen steht, hatte ich
vor einigen Tagen angemerkt. Aber abgesehen davon hat die cat.api
der Standardparameter den Abschnitt zur Indexierung der Zugangsnummer
im Bestellsatz deaktiviert:
ZgNum im Bestellsatz wird normalerweise nicht indexiert!
#9DB +#9DB ▼z "|9Z" e"/" ZgNr. aus Bestellsatz
#+#
#9DB b"/" r5
#+#
D.h. trotz Datenbanksperre bei der Nummernvergabe wird die hochgezaehlte Nummer
derart in die Datenbank geschrieben, dass sie zum Zeitpunkt der Freigabe der
Datenbank doch nicht in den Index kommt, andere Arbeitsplaetze haben damit
sehr lange Zeit (vor dem ersten indexierungsrelevanten Speichern der
Zugangsnummer liegen einige interaktive Elemente) die Chance, dieselbe Nummer zu
vergeben.
"Rettung" kann m.E. nur in einem ziemlich fundamentalen Umbau von o-invent.flx
bestehen, Zugangsnummern /muessen/ im Kontext der Erzeugung von Exemplarsaetzen
vergeben werden, anschliessend erst kann die Nummer in den Titelsatz uebertragen
werden, und danach kann evtl. der Exemplarsatz wieder geloescht werden.
[o-invent.flx sollte nextnum.flx includen, dann ist er schon einmal 100 Zeilen
kuerzer. Und alle Geschaeftsgangsvarianten sollten nicht als Kommentare im
Flex eingebaut sein, sondern ueber eine orda.inc oder invent.inc konfigurierbar
werden. Der Flex scheint auch einiges sowohl in Anwender- als auch in
$-Variablen redundanzt zu hinterlegen (etwa #uzg und $Zugnr), insgesamt ist er
sehr undurchsichtig...]
viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBStzrO2ITJZieluOzAQL4FQP/WQ7FEKRnCpb5WZqfyAjkYqHQLxoll2zi
QWntG35xPs84Ta0DYxHRo7J8XvqyGVgmoFzkRdH2UbIlITcBiXYu7WkaM6za82LJ
suEWOXrMBQy0z3S2sGH1R8VGVaaIBSjrX5WNxFHAHvpXjFQBr3RymfknmkB9xPf+
d/fz+NnwCf8=
=AsUL
-----END PGP SIGNATURE-----
Mehr Informationen über die Mailingliste Allegro