Fehlermeldung: Zugriff auf DBF gesperrt

[ggscholz]

Hallo in die Runde,

ich lese Daten per SQL SELECT Abfrage aus einer dbf-Datei mit den Komponenten TUniConnection, TDBFUniprovider und TUniQuery aus. Die Datei hat ca.250 Datensätze, ich lese in einer Zeile ein Feld aus.

Code:

SELECT USERID FROM TSTAMP WHERE TAGID = :p1

Delphi-Quellcode:

DbModul.qryTsUserId.Params[0].Value := UserName;
DbModul.qryTsUserId.Open;
UserNbr := DbModul.qryTsUserId.Fields[0].AsString;
DbModul.qryTsUserId.Close;

Das Programm, das die Datenbank mitgeliefert hat, wird wohl mit FoxPro entwickelt worden sein.

Es kommt vor, das eine Fehlermeldung aufplopt:

Code:

Datei TsUserId.dbf kann nicht geöffnet werden. Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

Ich bin leider nicht so Fit mit diesem ja schon relativ alten Datenbankformat. Wie kann ich in Delphi prüfen, ob die dbf-Datei gerade gesperrt ist.

In der Komponente TUniConnection und TUniQuery gibt auch viele für mich nicht ganz verständliche Optionen, um den Zugriff auf die dbf zu steuern. Gibt es dort eventuell Möglichkeiten, die Sperre der Datei abzuwarten?

Wo wird in dem dbf-System eventuell die Datensperre verwaltet??

Gibt es eine bessere Möglichkeit, auf die dbf-Datei lesend zuzugreifen?

Ich bin für jeden Hinweis dankbar

Mit besten Grüßen

Gerd

[Delphi.Narium]

Es kann bei 'ner DBF für gewöhnlich nur ein einzelner User auf die Datenbankdatei zugreifen. Mehrplatzbterieb oder Zugriff über mehrere Instanzen eines Programmes von einem Rechner scheitern für gewöhnlich mit einer derartigen Fehlermeldung. Selbst zwei Selects über zwei Querykomponenten, aus einem Programm heraus, können zu dieser Fehlermeldung führen.

Wenn Du z. B. in der IDE die Query geöffnet hast und dann das Programm aus der IDE (z. B. im Debugger / aber auch ohne Debugger) startes, wird das Öffnen der Query im Programm (höchstwahrscheinlich) mit dieser Fehlermeldung enden.

Stelle sicher, dass in der IDE keine Verbindung, keine Query geöffnet ist, sondern erforderliche Verbindungen zur DB erst zur Laufzeit geöffnet werden und Abfragen per Query erst unmittelbar vor deren Verwendung und nur solange wie zwingend erforderlich offen gehalten werden.

Ob TUniConnection, TDBFUniprovider und TUniQuery über Attribute verfügen, mit deren Hilfe man das Problem ggfls. reduzieren oder vermeiden kann, weiß ich nicht. Mit der BDE ging das früher in geringem Umfang, aber die ist inzwischen sowas von Schnee von gestern, dass sie als alternative Zugriffsschicht wohl eher ausscheidet.

[mlc42]

Falls ein Virenscanner läuft mal eine Ausnahme auf den Ordner der DB definieren.

[Alfredo]

Unter Delphi 12.1 habe ich gute Erfahrungen mit Adoconnection, Adoquery und dem ODBC-Driver(32bit) vfpodbc.dll 6.01.8629.01 vom 07.12.1999 gemacht.

Leider weiss ich nicht mehr wie der auf den Entwicklungsrecher gekommen ist und wo man den heute herbekommt.

Gruß
Alfred

[Delphi.Narium]

Die sind bei Windows in der ODBC-Verwaltung immer mit dabei, die scheint Microsoft da immer mit zuliefern, genauso wie die für Access, Paradox, Excel, Text und SQL-Server.

[ggscholz]

Ich habe jetzt Verschiedenes probiert, aber so richtig funktioniert es nicht: es sind 2 DBF Dateien, die ich abfragen möchte, bei der einen läuft es eigentlich immer ohne Fehler durch, die zweite sperrt sich aber immer gegen meine Leseversuche. Eventuell passt auch die Fehlermeldung nicht zur Ursache. Ich werde weiter suchen...

Ich hab auch noch nicht herausbekommen, wie ich den Prozess, der die DB sperrt, finden kann.

Ich helfe mir jetzt damit, das ich mir die Datei außerhalb der Arbeitszeiten in ein eigenes Verzeichnis kopiere. Auch wenn das mich nicht wirklich zufrieden stellt, es funktioniert erstmal. Die kopierten Daten sind für 24 Stunden ausreichend aktuell.

Trotz allem, Danke für die Hilfe!!

Beste Grüße

Gerd

[Delphi.Narium]

Zitat:

Ich hab auch noch nicht herausbekommen, wie ich den Prozess, der die DB sperrt, finden kann.

Alle Rechner neustarten, die auf die Datei zugegriffen haben könnten. Eventuell ist bei einem Programmabsturz "nur" ein Handle offen geblieben, das nun suggeriert, die Datei sei aktuell im Zugriff von wem auch immer. Programmabstürze können bei DBF-Dateien zuweilen zu diesem Effekt führen.

Den "Übeltäter" finden könntest Du eventuell so:

Code:

Microsoft Sysinternals Process Explorer

Process Explorer öffnen: Starten Sie den Process Explorer als Administrator.

Handle oder DLL suchen: Klicken Sie auf das Fernglas-Symbol (Find Handle or DLL) oder drücken Sie STRG + SHIFT + F.

Dateinamen eingeben: Geben Sie den Dateinamen oder den Pfad der gesperrten Datei ein und klicken Sie auf „Search“.

Prozess identifizieren: Der Prozess, der die Datei verwendet, wird in der Liste hervorgehoben. Sie können den Prozess beenden, indem Sie den Eintrag markieren und die Entfernen-Taste drücken.

Kann funktionieren, muss aber nicht.

[Alfredo]

Ich würde mal mit einem Hexeditor prüfen was im ersten Byte der beiden dbf-Dateien
steht.

Man könnte aber auch die dbf mit LibreOffice Calc öffnen um zu sehen ob die Datei
ok ist.

[BerndS]

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.

[Alfredo]

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

Gibt es denn eine *.cdx?

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

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

[Alfredo]

Zitat:

Zitat von himitsu (Beitrag 1541653)

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

Oder muss ich den Fehler anders interpretieren.

[himitsu]

Wie gesagt, "eigentlich". :stupid:

Von Seite des Grids, sollte es dennoch mit NULL umgehen können.

Wenn datenbankseitig ein Feld als NOT-NULL deklariert sein sollte
und das clientseitig auch beachtet wird (also das Required im TField von der DB-Query-Komponente gesetzt wird),
dann wäre das eine andere Sache ... hat dann aber nichts mit dem Grid zu tun, bzw. Delphi/Grid sind dann nicht Schuld.

Aber normal prüfen die meisten DB-Query-Komponenten das Required erst im BeforePost, aber nicht beim Laden/Open/Refresh. :gruebel:

[Alfredo]

:roll:

Jetzt arbeite ich 30 Jahre mit Foxpro/VFP und dann beherrsche ich die Grundlagen nicht.

Man muss in der *.dbf beim Feld Anschrift bei NULL einen Haken setzen und dann schnurrt alles.

Ich dachte immer beim Haken darf das Feld nicht NULL sein.