Fehlermeldung: Zugriff auf DBF gesperrt

[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.

[johndoe049]

Zitat von Delphi.Narium:

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.

Oder man zieht mal das Netzwerkkabel bei einer Mehrplatzumgebung raus, startet die Delphi Software lokal und hat dann auch mehr Informationen über das Problem.

[Alfredo]

Zitat:

von johndoe49:
Wo gibts es die Probleme?

In Delphi.

Mein Denkfehler war im Grid das Memofeld anzuzeigen.

Wenn der Cursor auf das Feld sprang und wieder heraus ging,
bekam ich einen ODBC-Fehler wegen einem Nullwert des Memofeldes.

Lösung: Keine Anzeige des Memofeldes im Grid.

[himitsu]

Per se sollte es aber eigentlich keinen Fehler geben, wenn ein Memo-Feld sich mit NULL im Grid befindet.