BDE hängt!

[smaug]

Hallo,

ich verwende 3 Programme, die über BDE auf Datenbanken zugreifen.
Ein Server, der als Dienst läuft, eine Client-Oberfläche und ein C-Programm mit einer in Delphi geschriebenen DLL.
Das C-Programm wird vom Server mit CreateProcess gestartet.

Wenn alle drei zusammen laufen, hängt die BDE.
Die DLL kommt dabei als letztes, öffnet eine Tabelle, schreibt einige Sätze und schließt sie wieder. Alles ohne Fehler.
Das seltsame ist, dass das C-Programm bis zum Ende durchläuft, GetExitCodeProcess mir aber 128 zurückliefert. Beim nächsten Zugriff auf Tabellen frieren sowohl Server als auch Client ein. Genauer gesagt: TTable.open auf dem Server kehrt nicht zurück; das mit einer TQuery verbundene DBGrid wird nicht mehr gezeichnet.

In allen drei Programmen verwende ich dasselbe NetDir und jeweils ein eigenes PrivateDir. Der Client erzeugt allerdings auch LCK-Dateien im DB-Verzeichnis!?
Das ganze läuft auf Win200 Workstation. BDE Version 5.11. Der Benutzer hat Amdinrechte, der Dienst läuft unter System.

LOCAL SHARE steht auf true, damit ich die LCK-Dateien besser verfolgen kann. Das macht aber keinen Unterschied.

Ich hab' keine Ahnung mehr wo ich den Fehler noch suchen soll.

[mkinzler]

Was<macht ie Dll genau? Vielleicht erzeugt diese Locs die nicht mehr entfernt werden?

[Bernhard Geyer]

1, Um zu checken ob du nicht einfach Speicherlücken im Bereich DB-Komponenten hast häng mal FastMM4 rein

2, Von deinem geschilderten System von einem Client und Server zu reden ist etwas zu viel des guten. Wenn es wirklich Client/Server wäre, hättest Du den DB-Zugriff und die Kompos eh nur auf dem Server und eine passende Schnittstelle wie die anderen Komponenten mit dem Server kommunizieren.

3, Nur der obligatorische Satz: Schmeiß die BDE weg. Wie du merkst bekommt man (trotz der Betrachtung aller möglichen bekannten) Fehlerquellen immer wieder Probleme. Aber ich will nicht weiter ausholen. Probier erstmal Punkt 1 um zu sehen obs evtl. nur "triviale" Speicherlücken sind.

[smaug]

Die DLL wird mehrfach aufgerufen.
Beim ersten Mal wird PrivateDir und NetDir von Session gesetzt und eine Tabelle geöffnet, die von den anderen beiden Programmen nicht verwendet wird, aber im gleichen Verzeichnis liegt.
Bei jedem Aufruf wird ein Datensatz hinzugefügt oder geändert, die Tabelle bleibt dabei offen.
Beim letzten Aufruf wird die Tabelle geschlossen und freigegebn.
Ausser schreiben in eine Logdatei, die auch sauber geschlossen wird, macht die DLL nichts.

Ich werde die Programm von nun an Dienst und Oberfläche nennen, ok? Eine Schnittstelle für schreibenden Zugriff auf die Datenbanken ist übrigens vorhanden. Die Oberfläche öffnet nur TQuerys und TTable im Browse-Modus.

FastMM hab ich in uses eingebunden. Im C-Programm allerdings nicht, das ist nicht mit Borland kompiliert. Und nu?

[smaug]

Wenn die Oberfläche zu ist und die DLL somit sauber durchläuft, bleiben auch kein LCK-Dateien liegen.

[Bernhard Geyer]

Zitat:

Zitat von smaug

FastMM hab ich in uses eingebunden. Im C-Programm allerdings nicht, das ist nicht mit Borland kompiliert. Und nu?

Muss noch mit Debug-Infos im FullDebugMode arbeiten damit auch FastMM meckert.

[smaug]

Das ist interessant, mit FastMM bleibt jetzt schon das C-Programm hängen, die BDE bleibt aber verschont, sofern die Oberfläche keine Query offen hat.
Hat die Oberfläche eine Query offen, kommt das C-Programm weiterhin mit 128 zurück und es wird keine Logdatei erstellt.

Im MemoryManager_Event.log findet sich

Zitat:

5 - 12 bytes: TIniFile x 1
13 - 20 bytes: TObjectList x 3, Unknown x 3
21 - 28 bytes: TCriticalSection x 1
29 - 36 bytes: TWinHelpViewer x 1
37 - 44 bytes: String x 1
45 - 60 bytes: THelpManager x 1

Das IniFile habe ich definitiv freigegeben, der Rest ist mir vollkommen unbekannt ...?

[Bernhard Geyer]

Hast Du TWinHelpViewer und THelpManager kannst Du vergessen. Evtl. auch noch die Units von Helpware im Einsatz. Fehler ist dort zu suchen bzw. in WinHelpViewer.pas und HelpIntfs.pas

Pack noch Debug-DCU's dazu und schau dir mal die Log-Dateien an. Dort ist der Aufrufstack für deine Speicherlücken drin.

[smaug]

Mit den Helpdingern hab ich nix zu schaffen:

Zitat:

[HelpIntfs.pas][HelpIntfs][THelpManager.Create][293]
[FastMM4.pas][FastMM4][DebugGetMem][6000]
[HelpIntfs.pas][HelpIntfs][GetHelpSystem][274]
[system.pas][System][@NewAnsiString][11530]
[Forms.pas][Forms][TApplication.ValidateHelpSystem][7109]

[WinHelpViewer.pas][WinHelpViewer][initialization][655]
[system.pas][System][InitUnits][10548]
[system.pas][System][@StartLib][10710]

Dafür hab ich die Critical Section gefunden und elimiert. Ausserdem hatte sich doch noch ein IniFile-Object in einer anderen Unit versteckt. Hat leider nichts gebracht.

Die eingebundenen Units
uses Sysutils, IniFiles, Classes, DBTables, FileCtrl;

[smaug]

Ich hab das Ganze mal ausführlich debugt. Beim Beenden der DLL gibt's eine Access Violation.

Das letzte, was ich im Quellcode zu sehen kriege, ist DLLDetachCallback in DBTables. Im Assembler komm ich dann noch bis call idapi32.dbiEXT. Irgendwo da drinnen kracht's dann.

[Bernhard Geyer]

Ergänz mal eine gesonderte Close-Funktion in deiner DLL. Hatte auch mal den Probleme wenn die DB-Verbindung erst beim finalization der Units bzw. beim Destruktor der Units geschlossen wurde. Hier wars aber da in meinem Fall die Screen-Instanz nicht mehr vorhanden war.

[smaug]

Die TTable hab ich natürlich geschlossen. (Wenn sie offen bleibt macht's aber auch keinen Unterschied.)
Oder meinst du eine andere Close-Funktion?

[Bernhard Geyer]

Zitat:

Zitat von smaug

Die TTable hab ich natürlich geschlossen. (Wenn sie offen bleibt macht's aber auch keinen Unterschied.)
Oder meinst du eine andere Close-Funktion?

Auch TDatabase geschlossen?

[smaug]

TDatabase verwende ich gar nicht.
Hab's aber mal ausprobiert und eine Instanz erzeugt, macht (ja genau) keinen Unterschied.

Aber nochmal die Frage nach den LCK-Dateine im DB-Verzeichnis. Ist das normal, dass hier auch PARADOX.LCK und PARADOX.LCK liegen, zusätzlich zu denen im PrivateDir?

[Bernhard Geyer]

Zitat:

Zitat von smaug

TDatabase verwende ich gar nicht.
Hab's aber mal ausprobiert und eine Instanz erzeugt, macht (ja genau) keinen Unterschied.

Auch alle TTable-Instanzen darauf umgestellt und dann rechzeitig TDatabase-Verbindung geschlossen.

[hoika]

Hallo,

ich würde das DB-Verzeichnis mal auf einen anderen Rechner legen,
und in der Systemsteuerung(Computerverwaltung, Freigaben)
mir die geöffneten Dateien ansehen.

Lokal geht es auch über SysInternals (Processviewer)


Heiko

[smaug]

Wie kann ich TTable auf TDatabase umstellen? Die gleichnamige Eigenschaft ist doch readonly.
Und was heisst rechtzeitig?

[hoika]

Hallo

TDataBase.Directory auf dein Verzeichnis setzen oder AliasName auf den BDE-Alias
und bei allen TTable DataBaseName auf TDataBase.DataBaseName

Ich denke aber, bei Paradox-Tabellen nützt das nicht viel,
die Tabellen werden bei einem TDataBase.Connected=False (Close, oder was immer)
nicht geschlossen.
Es käme auf einen Test an.

Das kannst du aber auch über mein obiges Posting machen.


Heiko

[smaug]

TDatabase war über DatabaseName bereits richtig verknüpft und auch geschlossen.

Die LCK-Dateien kommen mir aber immer noch komisch vor.

(Wenn das Problem überhaupt hier liegt.)
In OnShow des Hautpfensters, das selber keine BDE-Komponenten hat, setze ich Session.PrivateDir. PDOXUSRS.LCK wird auch sofort dort angelegt. Soweit OK. Ausserdem wird dort TDatabase instanziiert.

Delphi-Quellcode:

Session.NetFileDir := path+'NET';
Session.PrivateDir := ExtractFilePath(ParamStr(0))+'CLIENT';

globalDatabase := TDatabase.Create(nil);
with globalDatabase do begin
  databaseName := 'MyDB';
  DriverName   := 'STANDARD';
  globalDatabase.Params.Add('PATH='+path);
  connected := true;
end;

Erst bei Bedarf werden Formulare kreiert.

Delphi-Quellcode:

object MyTab: TTable
   DatabaseName = 'MyDB'
   TableName = 'DATA.DB'
   object DataField1: TStringField
      FieldName = 'Field1'
      Size = 6
   end
end

In OnShow eines anderen Formulars wird dann eine TTable geöffnet. Jetzt erscheint auch eine PDOXUSRS.LCK im DB-Verzeichnis.

Soll das so sein??

[hoika]

Ja,

damit Paradox feststellen kann, ob eine Tabelle exclusiv geöffnet werden kann,
wird auch das blosse Öffnen einer Tabelle protokolliert (in ebend jeder LCK-Datei).


Heiko