AW: [Allegro] Gesperrte Datenbank

[Thomas Berger]

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

Lieber Herr Eversberg, liebe Liste,

| Da ist was dran.
|
| Abhilfe: Machen Sie sich einen _endflx.flx mit dem Inhalt
|
| if tbl mes "TBL gesperrt!";var "no"
|
| oder ergänzen Sie diese Zeile, wenn Sie schon einen _endflx.flx haben.
| Dann wird im Falle einer gesperrten TBL der Ausstieg verhindert (das
| bewirkt das "no" in der iV) und die Meldung ausgegeben, damit man
| Bescheid weiß.

Das scheint mir ziemlich krumm:

Es koennte sein, dass zufaellig in jener Millisekunde jemand
einen Satz speichert und daher die .tbl im Moment des Tests
voruebergehend gesperrt war: Dann gibt es vermeidbare
Irritationen.

Umgehen laesst sich das bekanntlich nur, indem man selbst
die .tbl sperrt, nur dann weiss man zuverlaessig, dass sie
vorher frei war:

set tbl lock

Nur: Wass passiert hier, wenn die Datenbank wegen einer Fehlersituatino
tatsaechlich permanent gesperrt ist: Dann haengt die Angelegenheit
unendlich lange und blockiert a99? (O.k. ich sollte mal testen,
ob "set tbl lock" ein eingebautes Timeout hat und einen Fehlercode
zurueckliefert...)

Meine Vorstellung ist, dass a99, wenn alles automatische scheitert,
letztendlich dem Benutzer die Frage stellt, ob (unter a) Verzicht aufs
Speichern der b) Verwerfen/Verlust aller Bearbeitungen und Neusaetze
beendet werden soll oder ob es noch einmal zu probieren ist.

Problem am Rande uebrigens, wenn wegen irgendwelcher Probleme a99 sich
auf access=0 zurueckgestuft hat: Dann sollten solche Tests beim
Beenden von a99 gar nicht erst versucht werden...

viele Gruesse
Thomas Berger

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

iQCVAwUBSAhV+GITJZieluOzAQJcdgP/cUPMGltdoIP8bGDDFlY5HMjMp48p10Er
6y9kTGJ8w3MI6gb4wrtRDMFlThKJalH1KO4ZQGTHvGPo2t1wHrQ8YcbTfOEgpWb5
QwFwk9FaLDlhHtMguF0LVrmn2T/vLgrK9VsCn0DLiDYDJVIIjuYrFHUtJAhaeYbf
Q1LE7iDDsQY=
=ZCWp
-----END PGP SIGNATURE-----