Fehlermeldung: Zugriff auf DBF gesperrt

[dummzeuch]

Zitat:

Zitat von BerndS (Beitrag 1541560)

Wäre denn eine Umstellung auf das direkte Lesen der DBF-Dateien denkbar.
Das könnte dann z.B. über TDBF https://sourceforge.net/projects/tdbf erfolgen.

Aber nur für Programme, die unter der GPL lizenziert sind oder die vom Entwickler eine andere Lizenz bekommen haben.

Letzteres geht aber eher nicht mehr, da eigentlich niemand eine solche Lizenz vergeben kann, selbst der originale Entwickler nicht, da inzwischen jede Menge andere zum Projekt beigetragen haben.

[BerndS]

Zitat:

Zitat von dummzeuch (Beitrag 1541565)

Zitat:

Zitat von BerndS (Beitrag 1541560)

Wäre denn eine Umstellung auf das direkte Lesen der DBF-Dateien denkbar.
Das könnte dann z.B. über TDBF https://sourceforge.net/projects/tdbf erfolgen.

Aber nur für Programme, die unter der GPL lizenziert sind oder die vom Entwickler eine andere Lizenz bekommen haben.

Letzteres geht aber eher nicht mehr, da eigentlich niemand eine solche Lizenz vergeben kann, selbst der originale Entwickler nicht, da inzwischen jede Menge andere zum Projekt beigetragen haben.

Ich bin nicht so der Experte für die LGPLv2.
Da habe ich die Antword vom Gemini wohl falsch verstanden.
Das meint Gemini dazu

[dummzeuch]

Zitat:

Zitat von BerndS (Beitrag 1541572)

Zitat:

Zitat von dummzeuch (Beitrag 1541565)

Zitat:

Zitat von BerndS (Beitrag 1541560)

Wäre denn eine Umstellung auf das direkte Lesen der DBF-Dateien denkbar.
Das könnte dann z.B. über TDBF https://sourceforge.net/projects/tdbf erfolgen.

Aber nur für Programme, die unter der GPL lizenziert sind oder die vom Entwickler eine andere Lizenz bekommen haben.

Letzteres geht aber eher nicht mehr, da eigentlich niemand eine solche Lizenz vergeben kann, selbst der originale Entwickler nicht, da inzwischen jede Menge andere zum Projekt beigetragen haben.

Ich bin nicht so der Experte für die LGPLv2.
Da habe ich die Antword vom Gemini wohl falsch verstanden.
Das meint Gemini dazu

Upps, da habe ich mich auf der verlinkten Seite glatt verlesen. Ich hatte das "L" bzw. "Lesser" übersehen.

Zitat:

Zitat von Gemini

Kombination mit proprietärer Software: Im Gegensatz zur GPL (General Public License) erlaubt die LGPLv2, dass die Software in proprietäre Programme eingebunden wird, solange bestimmte Bedingungen erfüllt sind.

Wobei zu klären wäre, was unter "solange bestimmte Bedingungen erfüllt sind" zu verstehen ist. Ich persönlich lasse bei der Entwicklung kommerzieller Software von allem, wo "GNU" drin vorkommt, die Finger. Um diese Lizenzen rechtssicher einzuhalten braucht man inzwischen ein Jurastudium, und zwar eines, das internationales Recht abdeckt.

Nochmal laut Gemini:

Zitat:

Zitat von Gemini

Konkrete Anforderungen:

Die genaue Umsetzung hängt von der Art der Verknüpfung und der Verteilung ab. Die LGPLv2 definiert verschiedene Szenarien und die damit verbundenen Anforderungen. Hier sind einige Beispiele:
...
Statische Verknüpfung:
Die Bibliothek wird direkt in Ihre Software eingebunden.
Sie müssen den Quellcode der gesamten Software (einschließlich der Bibliothek) zur Verfügung stellen.

Wenn das stimmt (für mich klingt das mehr nach GPL) dürfte man TDBF nicht eincompilieren sondern müsste Runtime Packages verwenden. Spätestens damit wäre es für mich außen vor.

[ggscholz]

Zitat:

Zitat von Alfredo (Beitrag 1541562)

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:

Zitat von Alfredo (Beitrag 1541616)

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:

Zitat von johndoe049 (Beitrag 1541618)

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:

Zitat von Delphi.Narium (Beitrag 1541643)

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.