Fehlermeldung: Zugriff auf DBF gesperrt

[Alfredo]

Die *.dbf könnte auch Teil einer *.dbc sein.

Gibt es denn eine *.cdx?

[ggscholz]

Zitat von Alfredo:

Die *.dbf könnte auch Teil einer *.dbc sein.

Gibt es denn eine *.cdx?

Ja die gibt's. Es sind 2 DBF Dateien beide haben eine CDX- Datei, eine der beiden Datei hat noch zusätzlich eine FPT Datei. Und ganau bei dieser diese zickt es beim öffnen.

Ich hab mich nicht weiter mit den Dateien beschäftigt und war davon ausgegangen, das der TDBFUniProvider von devart das hinbekommt, da alle Dateien im Verzeichniss vorhanden sind. Ich mache jetzt (hatte ich das schon geschrieben?) eine Kopie über Nacht in ein eigenes Verzeichniss, das ist für mich ausreichend aktuell und ich komme nicht mit anderen ins gehege. Es könnte ja auch mal sein, deis mein Programm die Verbindung nicht beendet.

Das Kopieren funktionert (bisher) ohne Fehler, 7zip weigert sich regelmäßig, weil andere auf die Dateien zugreifen. Seis drum, ich hab eine Lösung.

Und die weiteren Hinweise hier im Tread - herzlichen Dank dafür - ich komme zurecht, und ich schätze mal, das devart da nicht viel anders, ist als die genannte Komponente TDBF.

Beste Grüße

Gerd

[Alfredo]

Hier die Erklärung warum die 2. Datei zickt.

https://docs.fileformat.com/de/datab...rwendet%2C%20z.


Ich habe leider keine Erfahrung wie man auf Dateien mit Memofeldern zugreift.

[Alfredo]

https://www.independent-software.com...le-format.html

M.E. braucht die 2. Datei andere Zugriffsinformationen wie die einfache dbf.

[Alfredo]

Ich habe mal das mit dem Memofeld getestet.

Die FPT entsteht wenn man in VFP 9.0 ein Feld mit "memo" anlegt

Die CDX entsteht wenn man in VFP 9.0 ein Feld mit Index versieht.

In Delphi mit ODBC kann ich mir die testm4.dbf anzeigen lassen.

Das Feld Anschrift kann ich mir in TDBMemo anzeigen lassen.

Beim Erfassen und ändern der Daten gibt es jedoch derzeit Probleme.

Es liegt also hier eine einfache *.dbf mit Index und einem Memofeld vor.

[johndoe049]

Zitat von Alfredo:

Ich habe mal das mit dem Memofeld getestet.

Die FPT entsteht wenn man in VFP 9.0 ein Feld mit "memo" anlegt

Die CDX entsteht wenn man in VFP 9.0 ein Feld mit Index versieht.

In Delphi mit ODBC kann ich mir die testm4.dbf anzeigen lassen.

Das Feld Anschrift kann ich mir in TDBMemo anzeigen lassen.

Beim Erfassen und ändern der Daten gibt es jedoch derzeit Probleme.

Es liegt also hier eine einfache *.dbf mit Index und einem Memofeld vor.

Wo gibt es die Probleme? In der VFP Anwendung oder TDBMemo?

Es gibt übrigens nicht nur VFP9. Die gab es in 4 Versionen:
VFP9
VFP9 mit SP1
VFP9 mit SP2
VFP9 als Komplettdownload aus 2008. Sollte zwar identisch mit SP2 sein, war aber noch etwas aktueller.

Die englische Version hatte dann nochmal einen anderen Versionsstand.

Interessant ist diese information nur, weil sich das Dateihandling und das Verhalten der Runtime je nach Version unterscheidet. Wäre als hilfreich zu prüfen, ob die Runtime mit der Vollversion von VFP9, mit der die Anwendung erstellt wurde, auch übereinstimmt.

Bei einigen Anwendungen gab es den Effekt, dass zwar die dbf geschlossen wurde, aber der Dateihandler für die cdx Datei noch offen blieb. Auch bei Programmende der VPF Anwendung. Es gibt im Hintergrund noch eine VFP Runtime, die unabhängig von der Anwendung laufen kann, wenn die sich nicht selbst bei Programmende mit beendet. D.h. die kann eine Datei noch blockieren, auch wenn die Anwendung diese eigentlich schon geschlossen hat.

Das ODBC hat ein kleines bischen anderes Dateiformat als VFP9 ohne SP2. Es hab hierfür einen eigenen ODBC Update Treiber. Datei war die vfpoledb.exe aus 2006. Damit konnten dann alle Eigenheiten der dfb Struktur verwendet werden.

[Delphi.Narium]

Zitat von johndoe049:

Bei einigen Anwendungen gab es den Effekt, dass zwar die dbf geschlossen wurde, aber der Dateihandler für die cdx Datei noch offen blieb. Auch bei Programmende der VPF Anwendung. Es gibt im Hintergrund noch eine VFP Runtime, die unabhängig von der Anwendung laufen kann, wenn die sich nicht selbst bei Programmende mit beendet. D.h. die kann eine Datei noch blockieren, auch wenn die Anwendung diese eigentlich schon geschlossen hat.

Die Fehlermeldung klingt sehr stark nach diesem Effekt.

Kenne das aus früheren Zeiten mit der BDE. Dort konnte es auch passieren, dass Dateien gesperrt waren und blieben, bis man alle Programme, die irgendwie die BDE nutzten, beendet hatte. Beim "Killen" per Taskmanager konnten noch Handles offen bleiben, dann half nur ein Rechnerneustart.

Solange es sich beim Programm nicht um eine Mehrplatzsystem handelt, könnte es einen Versuch wert sein, den Rechner neu zu starten und dann sofort aus Delphi heraus auf die Dateien zuzugreifen, ohne dass das FoxPro-Programm gestartet wurde. Ist der Fehler dann weg, liegt es am oben beschriebenen Fehler. Andernfalls müssen alle Rechner mal neu gestartet werden ohne das FoxPro-Programm zu starten. Kann etwas mühselig werden, ist aber eventuell ein Ansatz zur Fehlereingrenzung.