UPDATE bleibt haengen

[Bernhard Eversberg]

Noch einige Punkte waren offen in den Fragen von Frau Koczian:

> 
> Nur, nach wie vor: koennen Speicherprobleme den Mehrfachzugriff
> beeintraechtigen? Warum laeuft UPDATE glatt durch, wenn niemand anderes
> zugreift (oder war das doch ein Zufall)? Da waren die Speichereinstellungen
> noch nicht korrigiert.
> 
Solche Beeintraechtigungen kann es von den Programmen her nicht geben, die
laufen voellig unabhaengig voneinander. Natuerlich muessen alle ohne -S
arbeiten.

> Und eine Frage, die ich am Anfang schon mal gestellt habe, und die noch in
> der Luft haengt: was kann man im Mehrplatzbetrieb mit SNIFFER gefahrlos tun
> und was nicht? Insbesondere, kann man Satztabelle und Datendateien
> _pruefen_, obwohl andere an der Datenbank arbeiten? Dass SNIFFER dann
> vielleicht einen Satz als gesperrt meldet und hinterher ist er wieder frei,
> das macht ja nichts.
> 
Alle SNIFFER-Funktionen, die nur lesen, sind gefahrlos. Das Freigeben
von Saetzen und der .TBL sind selbstredend schreibende Funktionen.
Wenn die Adressentabelle geprueft wird, kann es zu falschen Fehlermeldungen
kommen: wenn die .TBL gelesen wurde, kurz danach jemand anders den
Satz verlagert, und SNIFFER erst danach die Adresse ueberprueft.

> Und wie ist es mit dem Freigeben der Satztabelle? Da bekomme ich sowieso
> einen merkwuerdigen Effekt: vom Cockpit aus die Fehlermeldung
> "Zugriffsverletzung beim Lesen von Laufwerk K:", eigentlich regelmaessig,
> aber SNIFFER tut es.
> 
CockPit arbeitet wohl mit einem Zugriffsmodus, der unter Novell 
funktioniert, unter NT aber nicht. Mal sehen, ob wir das noch hinkriegen.

MfG B.E.




Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329, 
D-38023 Braunschweig, Germany
Tel.  +49 531 391-5026 , -5011 , FAX  -5836
e-mail  B.Eversberg at tu-bs.de