Probleme mit der .TBL-Datei

[Thomas Berger]

am Mittwoch Dr. Sibylle Koczian wrote:

> vorhin passierte folgendes (Umgebung: Windows NT 4.0 Server, PC's mit
> Windows 95 und WfW 3.11): permanente Meldung
> 
> >>> bitte warten, .TBL-Datei gesperrt
> 
> kein Speichern mehr möglich (aber eben dauerhaft, nicht mal eben
> kurzfristig). Organisieren / Datenbank freigeben ging nicht ("Fehler beim
> Lesen von Laufwerk k:"), trotz vorhandener Berechtigung. Satztabelle
> erneuern hat's dann schliesslich gebracht, aber:
> 
> Was kann passiert sein? Und wenn ich die Datenbank weder sperren noch
> freigeben kann, wieso kann ich dann die Satztabelle erneuern, alles vom
> gleichen Rechner und mit denselben Rechten?

Als Ergaenzung dazu:

folgendes Phaenomen ist beim Zentralinstitut fuer Kunstgeschichte
in Muenchen aufgetaucht und laesst sich dort seit einigen Wochen 
nicht abstellen. Ich habe es soeben mit Stephan Klingen, dem
dortigen Administrator soweit moeglich systematisch durchprobiert:

Server NT 4.0 Server SP3, Clients Win 95 (SP unbekannt):
Auf dem Server ist die Datenbank ueber ein DOS-Fenster
in Benutzung (ein Satz wird angezeigt, mehr nicht)

Vom Client jetzt folgende Aktionen:
V15-Executables: Satztabelle laesst sich via Cockpit nicht freigeben,
PRESTO nicht starten. Fehlermeldung jeweils:
"Fehler beim Lesen von Laufwerk K:" (dort liegt die Installation)
Auch ORDER vom 3.1.97 laesst sich (mit derselben Fehlermeldung)
nicht starten.
PRESTO vom 11.11.96 und ORDER vom 18.11 funktionieren hingegen.

Dasselbe unter derselben Benutzerkennung auf denselben Server
von einem NT 4.0 Workstation-Client aus durchgefuehrt, gibt _keine_
Probleme. 

Ist die Datenbank in der Server-DOS-Box nicht in Benutzung,
gibt es keine Probleme.

Ist die Datenbank von einem Windows NT-Client aus in Benutzung,
ebenfalls Probleme beim zusaetzlichen Aufstarten eines Windows-
95-Clients.

Ist die Datenbank von einem Windows-95-Client aus in Benutzung
(alte Executables), lassen sich die neuen Executables von einem
anderem Windows-95-Client ebenfalls nicht starten.

Auch bei dem Versuch, auf eine ansonsten unbenutzte Netzdatenbank
von einem Windows-95-Client doppelt zuzugreifen, scheitert.

Fazit: Waere die Meldung "unzulaessige Share Operation" (aber
vielleicht ist sie es ja nur in anderem Gewand) verhalten sich 
die Module ab zumindest Januar 1997 in der Kombination Win95-Client 
/ NT 4.0-Server so, als koennten sie auf die Datenbank uebers
Netz im Einzelplatzbetrieb(!) zugreifen. 
In diesem Zusammenhang faellt mir ein, dass ja gerade im Dezember 
die automatische Einzelplatz-Erkennung in die Allegro-Module 
aufgenommen wurde. Moeglicherweise kann man durch die Fehlermeldung
gerade die Erkennung "bei der Arbeit" sehen :-)

Bei der Kombination Server NT 4.0Server/ Client Win 95 gibt es 
also dieses Problem, dass ein Client mit neuen Executables
auf eine bereits geoeffnete Datenbank nicht zugreifen kann
(das umgekehrte, von einem NT 4.0-Client oder Server oder mit
alten Executables den _zweiten_ Zugriff zu machen, haben wir
leider zu testen vergessen)

Win 95 als Server bei ansonsten gleicher Konstellation scheint
zumindest mit 3.11 und Win 95-Clients o.k.

Damit zusammenhaengen koennte ein Problem, dass bei NT 3.51 Server
und ansonsten identischem Setup sporadisch Datensaetze (mit
korrespondierendem Eintrag in der .LOG-Datei) dupliziert werden,
insbesondere wohl bei globaler Manipulation.

Viele Gruesse
Thomas Berger