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

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

[MEissing]

(Ich weiß jetzt nicht, ob es das schon bei AnyDAC im Ggs zu FireDAC gab)

Bei FireDAC kann man über die FDConnection die Property "DataSetCount" auslesen.... ist die größer "0", dann gibt's noch Verbindungen.
Mittels <FDConnection>.DataSets[0.....n-1] kann man diese auch auslesen.....

[MichaelT]

Was passiert wenn du die BDE Connection nicht zumachst dasselbe oder du die zwei Statements umgekehrt anordnest?

Entlädt die BDE beim Connection Close die Client Library?

Der Fehler kam mir bestenfalls in multi-threaded Szenarien unter oder wenn es mit der Client Library was hat (aber an letzteres glaube ich so mal nicht).

Zitat:

Zitat von Cashew (Beitrag 1396860)

Hallo zusammen,

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


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

[Cashew]

Vielen Dank für die Antworten ...

@MEissing
Die AnyDAC hat bereits die Property DataSetCount.
Ich werde beim Schließen der Datenbankverbindungen jetzt eine Protokollierung einbauen, die über den DataSetCount prüft, ob noch Verbindungen offen sind...

@MichaelT
Bei dieser Exception habe ich leider das Problem, dass ich bisher keine Konstellation hinbekommen habe, in der der Fehler zuverlässig auftritt ...
Ich werde daher mal die Reihenfolge vom Schließen der Datenbankverbindungen, wie von Dir vorgeschlagen, umkehren... D. h. zuerst die AnyDac (FireDAC) Datenbankverbindungen schließen und dann die BDE Datenbankverbindungen ...


Könnte es auch sein das der ADManager Probleme macht? Würde es eventuell mein Problem lösen, wenn ich vor dem Schließen der AnyDAC (FireDAC) Datenbankverbindungen den ADManager deaktiviere:

Delphi-Quellcode:

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

[MichaelT]

Einfach probieren und rückmelden. Es wäre interessant ob die Client Library überhaupt entladen wird.

Dann müsste die BDE fliegen meiner Vermutung nach.

Ob das überhaupt parallel so friktionsfrei geht, kann ich mich nicht mehr erinnern. Ich habe BDE nie benutzt. Die Support Anfragen aus Zeiten von AnyDAC sind Jahre her. Ich kann mich erinnern, dass es mal was gab in die Richtung, aber nicht mehr mit welcher Version.

Die Interfaces auf der in der Meldung verwiesen wird sind jene auf mehrere Connections im Fall bspw. von Multithreading gegenüber einem Oracle Session Pool werden gehalten.

Die dürften dich im Normalfall gar nicht berühren. Weswegen eher der Verdacht nahe liegt, dass es irgendetwas mit der An- resp. Abwesenheit der Client DLL zu tun hat.

Zitat:

Zitat von Cashew (Beitrag 1396892)

Vielen Dank für die Antworten ...

@MEissing
Die AnyDAC hat bereits die Property DataSetCount.
Ich werde beim Schließen der Datenbankverbindungen jetzt eine Protokollierung einbauen, die über den DataSetCount prüft, ob noch Verbindungen offen sind...

@MichaelT
Bei dieser Exception habe ich leider das Problem, dass ich bisher keine Konstellation hinbekommen habe, in der der Fehler zuverlässig auftritt ...
Ich werde daher mal die Reihenfolge vom Schließen der Datenbankverbindungen, wie von Dir vorgeschlagen, umkehren... D. h. zuerst die AnyDac (FireDAC) Datenbankverbindungen schließen und dann die BDE Datenbankverbindungen ...


Könnte es auch sein das der ADManager Probleme macht? Würde es eventuell mein Problem lösen, wenn ich vor dem Schließen der AnyDAC (FireDAC) Datenbankverbindungen den ADManager deaktiviere:

Delphi-Quellcode:

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

[Cashew]

Zitat:

Zitat von MichaelT (Beitrag 1396872)

Was passiert wenn du die BDE Connection nicht zumachst dasselbe oder du die zwei Statements umgekehrt anordnest?

Entlädt die BDE beim Connection Close die Client Library?

Noch eine Nachfrage zu dem Thema... Wenn die BDE die Client Library entlädt, dann müsste ich doch immer die Exception bekommen, oder seh ich das falsch?

[MichaelT]

Ja. Du bekommst die Exception nicht immer?

Zitat:

Zitat von Cashew (Beitrag 1396899)

Zitat:

Zitat von MichaelT (Beitrag 1396872)

Was passiert wenn du die BDE Connection nicht zumachst dasselbe oder du die zwei Statements umgekehrt anordnest?

Entlädt die BDE beim Connection Close die Client Library?

Noch eine Nachfrage zu dem Thema... Wenn die BDE die Client Library entlädt, dann müsste ich doch immer die Exception bekommen, oder seh ich das falsch?

[Cashew]

Zitat:

Zitat von MichaelT (Beitrag 1396901)

Ja. Du bekommst die Exception nicht immer?

Nein, ich konnte bisher noch nicht nachvollziehen wann der Fehler auftritt... Sorry hatte ich in meinem ersten Post nicht erwähnt, ich werds noch ergänzen...

[MichaelT]

Am schnellsten geht es vermutlich wenn du dich in die

Delphi-Quellcode:

TFDPhysManager.InternalClose(ATerminate, AWaitForClose: Boolean);

in der FireDAC.Phys reinhängst.

Delphi-Quellcode:

finally
    iStartTime := TThread.GetTickCount();
    while not lTimeOut and (FDriverList.Count > 0) do begin
      lTimeOut := FDTimeout(iStartTime, C_FD_PhysManagerShutdownTimeout);
      CleanupDrivers;
      Sleep(1);
    end;
    if FDriverList.Count = 0 then
      if FState = dmsTerminating then
        lFree := True
      else if FState = dmsStoping then
        CleanupManager;
    if lTimeOut then
      FDException(nil, [S_FD_LPhys], er_FD_AccShutdownTO, []);
    if lFree then
      FDFree(Self);
  end;

er_FD_AccShutdownTO Dabei handelt es sich um die im Beitrag zitierte Fehlerkonstante die nur dort wird abgesetzt.

Der Fehler tritt im Finally Block auf. Ich schätze mal das Problem tritt im Umfeld der CleanUpDrivers auf. Wäre nur meine Vermutung.

[hoika]

Hallo,
die BDE entlädt die Dll nicht, das macht Windows.
Und erst, wenn alle Programme sie per FreeLibrary freigeben haben.

Denke ich mal vorsichtig.


Warum Disconnectest Du dich überhaupt?
Das macht doch die TAdConnection selber.

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

Zitat von Cashew (Beitrag 1396860)

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:

Zitat von MichaelT (Beitrag 1396905)

Am schnellsten geht es vermutlich wenn du dich in die

Delphi-Quellcode:

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:

Zitat von hoika (Beitrag 1402419)

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:

Zitat von hoika (Beitrag 1402477)

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:

Zitat von hoika (Beitrag 1402477)

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:

Zitat von hoika (Beitrag 1402477)

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:

Zitat von MichaelT (Beitrag 1402493)

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:

Zitat von MichaelT (Beitrag 1402493)

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:

Zitat von Cashew (Beitrag 1402653)

Moin Moin...

[hoika]

Hallo,

Zitat:

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

Dann ist das also schon freigegeben worden, aber die Klasse, die das Objekt enthält, weiß nichts davon.
Normalerweise informiert eine solche Klasse seinen "Visitor", dass sie freigegeben wird.

Hier hilft nur ein Minimalprojekt, was den Fehler verursacht.
Ich denke, sogar FastMM4 hilft hier nicht, weil es nur die 2. Stelle findet,
wo der Zugriff bereits nicht mehr klappt, weil das Objekt nicht mehr existiert.

Viel "Spaß" beim Debuggen (nicht böse gemeint).

Ein Ansatz wäre ein Loggen von ClassName, Name (oder was auch immer sinnvoll ist)
und das schrittweise Ausführen des Codes, um festzustellen,
ab wann das Objekt in der Liste nicht mehr gültig ist.
Ich empfehle eine Logdatei, die immer wieder den Class/Name (was auch immer) aller
Klassen in der Liste schreibt.
Die kann man sich per Notepad++ immer aktuell ansehen.

[Cashew]

Zitat:

Zitat von hoika (Beitrag 1402707)

Hallo,
Hier hilft nur ein Minimalprojekt, was den Fehler verursacht.
Ich denke, sogar FastMM4 hilft hier nicht, weil es nur die 2. Stelle findet,
wo der Zugriff bereits nicht mehr klappt, weil das Objekt nicht mehr existiert.

Viel "Spaß" beim Debuggen (nicht böse gemeint).

Mit dem "Minimalprojekt" hab ich gestern bekommen und hab schon meinen "Spaß" :lol:


Vielen Dank für Eure Hilfe...

[Cashew]

Hallo,

nach einiger Zeit des Debuggens haben wir zwei Fehlerursachen gefunden. Meine Testanwendung ist wie folgt aufgebaut:

• Eine Hauptform vom FormStyle = fsMDIForm.
  Diese Form beinhaltet zwei TDatabase Komponenten (BDE) und zwei TADConnection (AnyDac) sowie Buttons zum Aufrufen von MDI Child Forms
  
  
• Eine MDI Child Form (FormStyle = fsMDIChild). Diese Form arbeitet mit den folgenden Controls (welche natürlich miteinander Verbunden sind):
  • 1x TADTable
  • 1x TDataSource
  • 1x TDBNavigator
  • 1x TDBEdit (dem DateField ist ein Feld vom Typ TStringField zugewiesen)
  • 1x TDBMemo (dem DateField ist ein Feld vom Typ TMemoField zugewiesen [DB Field Typ = Blob])
  • 1x TEdit
    
    
  • Die DB Controls sind natürlich miteinander verbunden...

Die hier im Thread beschriebene EAccessViolation tritt auf, wenn mehrfach (2-3 mal) unterschiedliche Datensätze geändert werden und hierbei entweder:

• in den FetchOptions.Items der TADTable fiBlobs ausgeschlossen wurde

und/oder

• im TADTable Event BeforeEdit die Methode RefreshRecord aufgerufen wird.
  Anmerkung: Es kommt zu keiner EAccessViolation wenn RefreshRecord an anderer Stelle aufgerufen wird. Zum Beispiel über den Refresh Button des TDBNavigators.

Andere Optionen die in der TADTable verändert wurden (z. B. FormatOptions.MapRules, DetailFields, UpdateOptions.KeyFields, ...) konnten wir ausschließen. Des Weiteren wurden auch in der TADConnection keine besonderen Veränderungen vorgenommen.

Hat jemand eine Idee, warum es durch das ausschließen von fiBlobs aus den FetchOptions.Items, oder durch das Verwenden von RefreshRecords im Event BeforeEdit, zu solchen Problemen kommen kann?
Machen wir vielleicht beim Abrufen der Blob Daten etwas falsch?