AnyDAC (FireDAC) - Exception beim schließen einer TADConnection

[Cashew]

@MichaelT
Vielen Dank für deine detailierten Infos... Aufgrund von anderen Problemen bin ich gestern leider nicht dazu gekommen das Thema weiter zu verfolgen...

Wie bereits erwähnt habe ich in unseren Anwendung die folgenden Änderungen vorgenommen:

• Geänderte Reihenfolge beim Schließen der Datenbankverbindungen (zuerst AnyDAC/FireDAC dann BDE). Ergebnis: Exception kommt immer noch
• Protokollierung zum prüfen des <TADConnection>.DataSetCounts eingefügt. Ergebnis: Exception kommt immer noch und die DataSetCounts sind = 0, bei beiden <TADConnections>

Ich werd mich jetzt dann mal ins InternalClose reinhängen wie von dir Empfohlen...


@hoika
Naja, gehört doch eigentlich dazu das man seine Connections schließt wenn man sie öffnet?!

[hoika]

Hallo,
ja, eigentlich schon

Aber: Was passiert denn, wenn Du Dein Close/Free wegläßt, kommt dann immer noch die Exception?

Prinzipell sollte man natürlich alles schließen, was man selbst geöffnet hat.
Ich würde mal ein leeres Projekt mit ausschließlich dem BDE-Open/Connect FD-Open/Connect und dem Close/Free machen.
Meistens ist es nämlich eine andere Stelle, die das Problem verursacht und nur zufällig im Close/Free den Fehler erzeugt,
z.B. doppeltes Free oder irgend eine andere Speicherverletzung.

Du solltest mal FastMM4 auf Dein Programm loslassen, um sowas zu prüfen.

[MichaelT]

Original von der Antwort vom Dmitry.

At first it is too old FireDAC version …

This probably is not because BDE and FireDAC are used in the same application.

Many possible reasons:
* consequence of some incorrect multy-threading;
* incorrect use of FireDAC in a DLL;
* some FireDAC connection or query object is not released;
* some FireDAC incorrect usage leading to a bug in FireDAC.

---

Also irrte ich mich bezüglich BDE und FireDAC gemeinsam in einer Anwendung zu verwenden geht offensichtlich. Ist mal kein Schaden. An sich kann man das ausschließen was das Experiment mit dem neu sortieren der Statements schon zeigte.

Zitat von Cashew:

Hallo zusammen,

wir sind gerade dabei unsere Delphi 7 Anwendung von der BDE Komponente auf die AnyDAC 8.0.5 (FireDAC) Komponente umzustellen...

Während der Umstellungsphase verwenden wir in unserer Anwendung beide Komponenten. Das heißt für die BDE Datenbankverbindung verwenden wir eine TDatabase und für die AnyDAC (FireDAC) Datenbankverbindung verwenden wird die TADConnection.

Im Event OnCloseQuery der Hauptform werden die Datenbankverbindungen geschlossen:

Code:

procedure TfrmMain.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  [...]
  try
    BDEConnection.Connected := False;
  except
    on e:exception do
      MessageDlg('BDEConnection' + #13#10 + e.message, mtError, [mbOK], 0);
  end;
  //--------------------------------------------------------------------
  try
    dacConnection.Connected := False;
  except
    on e:exception do
      MessageDlg('dacConnection' + #13#10 + e.message, mtError, [mbOK], 0);
  end;
  [...]
end;

Beim schließen der AnyDAC (FireDAC) Datenbankverbindung erhalten wir die folgende Exception:

Zitat:

[FireDAC][Phys]-334. ADPhysManager shutdown timeout. Possible reason: application has not released all connection interfaces

IMHO sollten alle Queries, Tables, Transaktionen, etc. geschlossen sein...

Hat jemand schon mal diesen Fehler? Oder eine Idee woher der Fehler kommen könnte?

Edit: Die Exception erhalten wir nicht immer! Bisher konnten ich leider nicht nachvollziehen wann der Fehler auftritt!

[Cashew]

Hallo zusammen...

seit heute beschäftige ich mich wieder mit der Exception, die ich beim Schließen der AnyDAC Connection erhalte.

Folgenden Vorschlag werd ich mir jetzt als Nächstes anschauen:

Zitat von MichaelT:

Am schnellsten geht es vermutlich wenn du dich in die

TFDPhysManager.InternalClose(ATerminate, AWaitForClose: Boolean); in der FireDAC.Phys reinhängst.

Folgendes habe ich heute noch versucht, leider ohne Erfolg:

• Programm beenden ohne die TADConnection zu schließen
• TADConnection schließen und auftretende Exceptions unterdrücken:
  
  Delphi-Quellcode:

     procedure TfrmMain.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
     begin
       [...]
       try
         dacConnection.Connected := False;
       except
       end;
       [...]
     end;

[hoika]

Hallo,
das bist doch du, oder ?
https://stackoverflow.com/questions/...ose-connection

Hast Du die Stelle mal debuggt
if TObject(FClients[I]) is TDataset
Du könntest auch den Code der kompletten Routine TCustomConnection.SendConnectEvent in Deinen eigenen Code packen
und mehr Log mitprotokollieren.

Wenn Du es nachstellen kannst, kommst du doch auch an den Namen des DataSets ran.

for I := 0 to FClients.Count - 1 do
Hier wäre doch ein Ansatz, alle DataSets zu durchlaufen und explizit zu schließen.


Ein ganz andere Ursache könnte auch ein Speicherfehler (Speicher überschrieben) sein,
der hier einfach Deine Connection vermurkst.
Nimm mal FastMM4 und prüfe, ob der Auffälligkeiten meldet.

Wenn es etwas Kosten darf, wäre auch PAL (Pascal Analyzer) interessant,
der findet viel mehr mögliche Probleme/Fehler als der Compiler.

[Cashew]

Zitat von hoika:

Hallo,
das bist doch du, oder ?
https://stackoverflow.com/questions/...ose-connection

Jupp, ich habs gestern bei Stackoverflow mal mit reingestellt...


Die Methode <TCustomConnection>.SendConnectEvent versucht ja den Connect oder Disconnect an die über <TCustomConnection>.RegisterClient registrierten Clients weiterzugeben. Bei der Fehlersuche ist mir aufgefallen, dass die Klasse TADConnection über eine Methode ReleaseClients verfügt. Meine Idee war dann diese Methode vor dem Schließen der Datenbankverbindung aufzurufen:

Delphi-Quellcode:

   procedure TfrmMain.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
   begin
     [...]
     dacConnection.ReleaseClients;
     //-----------------------------------------------------------------------
     try
       dacConnection.Connected := False;
     except
       on e:exception do
         MessageDlg('dacConnection' + #13#10 + e.message, mtError, [mbOK], 0);
     end;
     [...]
   end;

Dies hat nun den Effekt, das die Exception in der Methode ReleaseClients auftritt, und zwar an der folgenden Stelle:

Delphi-Quellcode:

procedure TADCustomConnection.ReleaseClients(AMode: TADReleaseClientMode = rmDisconnect);
var
  n, i: Integer;
  oDS: TADAdaptedDataSet;
begin
  [...]
  for i := CommandCount - 1 downto 0 do begin
    case AMode of
    rmFetchAll,
    rmClose:
      Commands[i].Close;
    rmOffline,
    rmDisconnect:
      begin
        n := CommandCount;
        Commands[i].Disconnect(True);  // <-- Exception
        if n = CommandCount then
          DetachClient(Commands[i]);
      end;
    end;
  end;
end;

Das Problem an der Stelle ist, dass laut CommandCount zwei TADCustomCommand Objekte vorhanden sein sollten. Tatsächlich ist aber nur ein TADCustomCommand Objekt vorhanden. Nun stellt sich mir die Frage warum der CommandCount falsch ist, oder ein TADCustomCommand Objekt nicht mehr verfügbar ist.

Da wir ja die BDE und AnyDAC Komponenten parallel verwenden, und der <TDatabase>.DatabaseName beziehungsweise der <TADConnection>.ConnectionName identisch ist, werde ich als nächste mal testen ob das Problem gelöst ist, wenn ich unterschiedliche Namen verwende, zum Beispiel:

Code:

  BDEConnection.DatabaseName    := 'conBDE'
  dacConnection.ConnectionName := 'conDAC'

[hoika]

Hallo,

Zitat:

Nun stellt sich mir die Frage warum der CommandCount falsch ist, oder ein TADCustomCommand Objekt nicht mehr verfügbar ist.

Laß Dir doch von beiden irgendwas eindeutiges anzeigen, ich nehme meist Name oder ClassName.
Das passt hier ja wohl nicht.

Es könnte sein, dass Du irgendein Command-Objekt doppelt freigibst oder "falsch" freigibst.
Was auch immer "falsch" bedeutet.

Kannst Du das ganze Problem nicht mit einer separaten Beispiel-Exe nachvollziehen,
die nur minimalen Code enthält?

[MichaelT]

Der Fehler kommt nicht von der Stelle. Der kommt von früher. Das Disconnect tut nichts. Die Implementierung ist leer.

Aus irgendeinem Grund ist der Handle auf die DB Session ungültig, vermutlich auf der Serverseite. An sich genügt es, auch wenn es nicht sauber ist die Excpcetion zu bügeln bis die Migration vorbei ist und dann eine passende Client Library zu suchen oder möglw. zuvor.

Es genügt ein isoliertes AnyDAC Beispiel um mal zu zeigen ob die Client Library an sich mal funktioniert. Hernach die BDE dazu tun. Irgendwann mal müsste sich das Phänomen zeigen.

Es gab Fälle in den die die anderen Komponenten einfach sagten, 'Danke und schönen Tag liebe DB'.

Ich kann mich noch an Fälle vor 8 erinnern als die großen Migrationswellen waren, da kam es hie und da vor, dass eine andere Library die Gegenseite.

Das Timeout kann viel sein. In der C-DLL eine Absturz. Die kennen keine Exceptions. Ich vermute am Client tracen hilft. Nach Bauchgefühl wohlgemerkt halte ich das für wahrscheinlicher. Wie du sagst ohne den Code. Wenn das Programm zuvor lief könnte ich mir vorstellen, dass entweder die DB wurde abgegradet oder die Library getauscht oder eine andere wird geholt aus irgendeinem Grund.

Zitat von hoika:

Hallo,

Zitat:

Nun stellt sich mir die Frage warum der CommandCount falsch ist, oder ein TADCustomCommand Objekt nicht mehr verfügbar ist.

Laß Dir doch von beiden irgendwas eindeutiges anzeigen, ich nehme meist Name oder ClassName.
Das passt hier ja wohl nicht.

Es könnte sein, dass Du irgendein Command-Objekt doppelt freigibst oder "falsch" freigibst.
Was auch immer "falsch" bedeutet.

Kannst Du das ganze Problem nicht mit einer separaten Beispiel-Exe nachvollziehen,
die nur minimalen Code enthält?

[Cashew]

Moin Moin...

Zitat von hoika:

Hallo,
Laß Dir doch von beiden irgendwas eindeutiges anzeigen, ich nehme meist Name oder ClassName.
Das passt hier ja wohl nicht.

Habe ich bereits versucht. Bei dem Objekt welches nicht mehr verfügbar ist, komme ich an die Info Name oder ClassName nicht mehr ran.

Zitat von hoika:

Kannst Du das ganze Problem nicht mit einer separaten Beispiel-Exe nachvollziehen,
die nur minimalen Code enthält?

Das ist jetzt mein nächster Versuch... Wie ganz am Anfang erwähnt, tritt dieser Fehler ja nicht permanent auf. Mittlerweile haben wir zwei Konstellationen über die wir den Fehler provozieren können, hier gilt es nun herauszufinden warum er immer an dieser Stelle auftritt.

Zitat von MichaelT:

Der Fehler kommt nicht von der Stelle. Der kommt von früher. Das Disconnect tut nichts. Die Implementierung ist leer.

Stimmt, der Fehler liegt an einem TADCustomCommand Objekt welches die AnyDAC freigeben möchte, aber nicht mehr verfügbar ist.

Zitat von MichaelT:

Es genügt ein isoliertes AnyDAC Beispiel um mal zu zeigen ob die Client Library an sich mal funktioniert. Hernach die BDE dazu tun. Irgendwann mal müsste sich das Phänomen zeigen.

Die AnyDAC ist funtionsfähig, auch wenn eine BDE dazukommt. Das haben wir über Test Projekte mittlerweile ausgeschlossen...

[MichaelT]

Gut. Danke für das Feedback. Dann muss ich für den Moment passen.

Zitat von Cashew:

Moin Moin...