Borland-Pascal Delphi 5: Probleme beim Filesharing

[Ulrich Blomeyer]

Habe das folgende Problem:
Zwei Applikation greifen auf denselben Datenbestand zu. Ein Programm ist unter Borland-Pascal 7 (DOS) entwickelt, das andere mit Hilfe von Delphi 5 (Windows). Die Datenbestände liegen in einer Datenbank mit DBase-Struktur. Ich verwende bei beiden Programmen das Datenbanktool Topaz (Version 7.51). Im Multiuserbetrieb erzeugen beide Applikationen eine Semaphorendatei (z.B. Daten.@D@) mit deren Hilfe offensichtlich gemanagt wird, welcher Client gerade Schreibrechte hat.
Startet die Windows-Anwendung zuerst, erzeugt also die Windows-Anwendung die Semaphorendatei, können alle User diese Datei gemeinsam benutzen, egal ob DOS-User oder Windows-User.
Startet die DOS-Anwendung jedoch zuerst, erzeugt also die DOS-Anwendung die Semaphorendatei, so können die Windows-Anwendungen die Semaphorendatei im Gegensatz zu den DOS-Anwendungen nicht öffnen!
Fehlermeldung: „Fehler Nr. 32 cannot open: c:\sp\afbak\dbf\daten.@d@ LOGIN“
Es handelt sich m.E. nicht um ein Datenbankproblem: Wenn man unter Delphi ein Assign und ein Reset dieser Datei probiert, so erhält man auch den E/A-Fehler 5.
Obwohl beide Anwendungen den gleichen Topaz-Sourcecode verwenden, scheint es einen Unterschied beim Dateihandling zwischen BP7 und D5 zu geben.
Ausgetest auf einen Windows-2000 PC und auf einem Linux-Server (Samba).

Any Ideas?

[Andreas Kosch]

Hallo,

wer derart antiquierte Mechanismen nutzt, sollte auch niemals ein modernes Betriebssystem einsetzen. Die Suche nach der Zeichenkette <b>OpLock</b> liefert hier im FORUM einige Anhaltspunkte (Registry-Einträge) zurück. Die modernen Windows-Versionen nutzen ein effizientes Sperrverfahren beim Zugriff auf die Dateien, so dass es bei der Koexistenz mit 16-Bit-Anwendungen zwangsläufig Probleme gibt

[Ulrich Blomeyer]

Ich benutze diese antiquierte Mechanismen nur deshalb, weil ich die sehr umfangreichen DOS-Anwendungen nicht abrupt, sondern nur gleitend auf ein modernes OS umstellen kann.
Nostalgie spielt keine Rolle!
Ich habe bisher zum Suchbegriff "OpLock" nichts direkt Verwertbares finden können. Ist es von Belang, dass beide Anwendungen (DOS + Win32) bzgl. der Dateiroutinen und DB-Routinen "denselben" Quellcode verwenden?
Wie ist es zu erklären, dass die Multiuserfähigkeit gegeben ist (also die friedliche Koexistenz), wenn die Win32-Anwendung <B>zunächst</B> und <B>anschließend</B> die Dos-Anwendung gestartet wird?
Mi

[Andreas Kosch]

Hallo,

&gt;..wenn die Win32-Anwendung zunächst und anschließend die ...

die neuen Windows-Versionen (ab Windows 2000) verwenden ein mehrstufiges Sperrverfahren (OpLocks) beim Zugriff auf Dateien, die über das Netzwerk geöffnet werden. Dieser Weg steht jedoch nur dann zur Verfügung, wenn keine ältere API-Funktion (16-Bit) die Datei bereits geöffnet hat

[Ulrich Blomeyer]

Vielen Dank.
Habe Ihren Hinweis mit Hilfe von Linux-Samba-Swat nachvollzogen: Stimmt!
Bei der DOS-Anwendung wird der OpLock-Status "None" ausgegeben, bei der Win32-Anwendung der OpLock-Status "Exclusive+Batch".
Also bleibt nur der "Work-Around" erst Win32 und dann DOS und möglichst bald keine alten API16-Aufrufe mehr verwenden?