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?