F: PV und DBN sperren

[Thomas Berger]

Oliver J. Kaftan wrote:

> Nach meinen Beobachtungen, wird eine Datenbank beim Speichern erst
> gesperrt,
> nachdem der Abschnitt "#u2 i4,s" der PV abgearbeitet worden ist. Wäre es
> 
> umgekeht, könnten in diesem Abschnitt mehrere eindeutige eindeutige
> Zahlen
> generiert werden fuer Siganturen, Zugangsnr. u.ae. Z.Zt. kann es im
> Netzwerk
> zu Konflikten kommen.

Aber die eindeutige Nummer lt cg-Befehl der .CFG ist dann
schon erzeugt? D.h., die Datenbank wird zweifach gesperrt:
einmal vor dem Hilfsabschnitt und einmal danach. Das halte
ich fuer unschoen.

Die Alternative, die Datenbank waehrend der Abarbeitung der
Phase "#u2 i4,s" gesperrt zu lassen, stelle ich mir aber
auch problematisch vor, da in vielen alten Anwendungen dort
der Code fuer den "normalen" Hilfsabschnitt durchlaufen
wird: Das koennte einen ziemlichen Zeitverlust bedeuten.

Herrn Lackhoffs Vorschlag wuerde bedeuten, dass die Datenbank
waehrend eines Abspeichervorgangs evtl. auch ein drittes Mal
gesperrt wird. Als Option vielleicht o.k., ich wuerde aber 
lieber P. Olivers Vorschlag folgen:

1.) .TBL sperren
2.) cg-Berechnung / Satznummernberechnung bei Neusatz?
3.) Hilfsabschnitt
4.) Satz speichern / umspeichern?
5.) LOG-Eintrag
6.) Schluesselberechnung
7.) Indexaenderung (und .STL und .RES)
8.) .TBL freigeben

Es ist also offensichtlich viel zu tun, waehrend der Bearbeiter
die Datenbank exklusiv fuer sich hat...

Wer dann Lastprobleme bekommt, sollte vielleicht seinen / ihren
Hilfsabschnitt erweitern um

#u2 +- i4,s

N.B.: "richtige" Kompatibilitaet zu vor v-15 erreicht man durch
#u2 +- I4,3
Der Modus 3 ist nicht im Handbuch dokumentiert, bezeichnet aber
den "klassischen" Durchlauf durch PV beim Einsortieren der Kategorie.

Viele Gruesse
Thomas Berger