AW: AW: [Allegro] A99: Suchen und Speichern

[Thomas Fischer]

Hallo Herr Eversberg,

> > Ich würde gerne wissen, wie das kommt und wie man das 
> verhindert (auch 
> > meine KollegInnen in Göttingen stoßen immer mal wieder auf 
> unvermutet 
> > gesperrte Datenbanken).

Mit "gesperrte Datenbank" meine ich natürlich gesperrte Satztabelle.
Der Punkt in org.rtf heißt ja auch "Datenbank sperren/freigeben"

Das geht ja auch schon aus der Fehlermeldung in meiner ursprünglichen Mail
hervor:

---------------------------
SAVE ERROR
---------------------------
.TBL gesperrt, Speichern nicht möglich
Datenbank freigeben per Menü 'Reorganisieren' (S. Handbuch S. 331)
---------------------------
OK   
-------------------------–

> Es kommt, wenn die Datei nicht zum Schreiben geöffnet werden kann.
> Dies wird i.d.R. Gründe haben, die außerhalb von allegro 
> liegen, denn allegro selber sperrt keine Datendateien, nur 
> die TBL und ADX sowie bei Bedarf den aktuellen Satz, nicht 
> aber die ganze Datei.
> Im Quellcode sehe ich aber jetzt, daß Veltkamp seinerzeit '98 
> noch eine Dateisperre auf das erste Byte des Satzes ergänzt 
> hat, aber nur für die Zeit, bevor die 8 da hingeschrieben 
> wird. Warum, steht da leider nicht. Es ist redundant, weil 
> die TBL in dem Moment schon gesperrt ist und deshalb sowieso 
> keiner überhaupt was schreiben könnte. Ich denke, wir nehmen 
> das besser mal da raus.
> Dieser Punkt *kann* allerdings nicht ursächlich sein, weil 
> die Fehlermeldung nicht darauf zurückzuführen ist, sondern 
> nur darauf, daß die Datei als solche und als Ganzes nicht zum 
> Schreiben geöffnet werden kann, und das hängt nicht an einem 
> einzelnen Byte.

Bezeiht sich das auf die andere Fehlermeldung

---------------------------
SAVE ERROR
---------------------------
file error: 4
---------------------------
OK   
-------------------------–

?

> > Ich habe in der entsprechenden Ergebnismenge jetzt noch einmal nach 
> > "Article" gesucht und 24 übriggebliebene Fälle gefunden (teils in 
> > *_3.gld, teils in *_4.gld).
> > Wie erklärt sich das? Kann ich den Datensätzen ansehen, 
> warum sie zu 
> > einer Sperrung der Satztabelle geführt haben? Oder waren nicht sie 
> > das, sondern der jeweils vorhergehende Satz?
> Dies alles kann von der Programmlogik her nicht sein.

Hm. Wer sperrt denn dann die Satztabelle? Kann es so etwas wie eine "Race
Condition" geben, dass das Programm schon versucht, den nächsten Satz zu
schreiben, wenn es mit dem aktuellen noch nicht fertig ist? Da gesperrte
Satztabellen immer mal wieder auftreten, muss es doch irgendeine Stelle im
Programm geben, wo die Sperre gesetzt wird. Und wenn irgend etwas schief
geht, wird die Sperre nicht gelöst.

> > 
> > Bei dem Versuch, diese noch einmal einer globalen Ersetzung zu 
> > unterziehen, blieben vier Treffer übrig, die sich nicht speichern 
> > ließen, weil der *Satz* gesperrt war. Auch da ist mir nicht 
> klar, wie das kommen kann.
> > Nochmalige Ersetzung mit jeweiligem Entsperren des Satzes ließ mich 
> > schließlich alle Speichern.
> > 
> Ja, die Sperre bleibt bestehen in solchen Fällen. Die Sperre 
> wird gesetzt, bevor das Speichern beginnt. Wenn das Speichern 
> gelingt, verschwindet die Sperre ohne explizites Aufheben, 
> weil dabei das erste Byte überschrieben wird (die 8 an der 
> Stelle ist das Flag für die Sperre, und da kommt dann die 1 hin).

Heißt das, dass die Satzsperre gesetzt wurde, und dann aber die Satztabelle
gesperrt wurde bevor der Satz geschrieben werden konnte?

> Das alles hat auch mit den genannten Funktionen nichts zu tun.
> Denkbar wäre höchstens noch ein Zusammenhang mit der 
> besonderen Art der Ersetzung, die Sie da machen: einen 
> Klartext durch ein Kürzel, das indexrelevant ist. Aber ich 
> müßte Beispieldaten zum Nachvollziehen haben, um das zu eruieren.

Die Daten kann ich derzeit nicht so einfach liefern, und der Fehler ist ja
auch erst einmal wieder verschwunden. Oder könnten Sie der Log-Datei etwas
entnehmen?

Mit freundlichen Grüßen
Thomas Fischer