Programm friert bei Open ein -> Fehler in gds32.dll

[RSE]

Delphi 5

Hallo,

der Fehler tritt unregelmäßig und unabhängig vom ausgeführten SQL an verschiedenen Stellen im Programm auf. Das Bild ist immer das gleiche: Zugriffsverletzung in CharUpperBuffA [2] während Query.Open [1] -> Query wird freigegeben [3] und das Programm hängt bei WaitForMultipleObjects [4].

Delphi-Quellcode:

  Query := TIBOQuery.Create(IB_Connection);
  try
    Query.IB_Connection := IB_Connection;
    Query.KeyLinksAutoDefine := GetEditableSelectResult;
    Query.RequestLive := GetEditableSelectResult;
    Query.SQL.Append(SQL);
    try
      Query.Open; // [1]
    except
      on E:Exception do
      begin
        Log('Fehler beim Öffnen der Query'#13#13 +
          'Fehlermeldung:'#13 + E.Message + #13#13 +
          'Fehlerverursachendes SQL:'#13 + Query.SQL.CommaText);
        raise; // Ausführung der Prozedur trotzdem abbrechen, Query freigeben
      end;
    end;
    try
      // Tue Was
    finally
      Query.Close;
    end;
  finally
    Query.Free; // [3] hier hängt er sich auf - siehe Callstack
  end;

Code:

7c91df48 +00a ntdll.dll                                    NtWaitForMultipleObjects           [4]
7c80958a +000 kernel32.dll                                 WaitForMultipleObjectsEx
7c80a110 +013 kernel32.dll                                 WaitForMultipleObjects
40547176 +003 gds32.dll                                    gds__thread_enter
40543b85 +065 gds32.dll                                    isc_dsql_free_statement
00522e77 +107 CCCClient.exe IB_Components                  TIB_Statement.SysUnprepare
005220b5 +065 CCCClient.exe IB_Components                  TIB_Statement.SysDeallocate
00521484 +030 CCCClient.exe IB_Components                  TIB_Statement.Unprepare
0055144f +01b CCCClient.exe IBDataset                      TIBODataset.Unprepare
005509a4 +014 CCCClient.exe IBDataset                      TIBODataset.Destroy                [3]
00403a5c +008 CCCClient.exe System               3530   +4 TObject.Free
00d55017 +137 CCCClient.exe CZ_Lib                351  +33 ExecuteSQL
0040423a +02a CCCClient.exe System               4715  +15 @HandleFinally
7c93ab7c +103 ntdll.dll                                    RtlUnwind
004041b6 +12e CCCClient.exe System               4654 +141 @HandleOnException
7c91e485 +009 ntdll.dll                                    KiUserExceptionDispatcher
7e36aebf +080 user32.dll                                   CharUpperBuffA                     [2]
40542ddb +16e gds32.dll                                    isc_dsql_execute2_m
40542bda +183 gds32.dll                                    isc_dsql_execute2
40542a4e +01a gds32.dll                                    isc_dsql_execute
00523ff0 +050 CCCClient.exe IB_Components                  TIB_Statement.API_Execute
00529d7d +005 CCCClient.exe IB_Components                  TIB_Dataset.SysExecSelect
00523219 +071 CCCClient.exe IB_Components                  TIB_Statement.SysExecStatement
00522f90 +098 CCCClient.exe IB_Components                  TIB_Statement.SysExecute
00529b98 +060 CCCClient.exe IB_Components                  TIB_Dataset.SysExecute
0052955f +10b CCCClient.exe IB_Components                  TIB_Dataset.SysOpen
0052919c +048 CCCClient.exe IB_Components                  TIB_Dataset.Open
00552798 +13c CCCClient.exe IBDataset                      TIBODataset.InternalOpen
004d1c9e +022 CCCClient.exe Db                   8260   +2 TDataSet.DoInternalOpen
004d1d6e +02e CCCClient.exe Db                   8289   +4 TDataSet.OpenCursor
004d1c09 +05d CCCClient.exe Db                   8242  +12 TDataSet.SetActive
004d1a6a +00e CCCClient.exe Db                   8203   +1 TDataSet.Open                      [1]
00d54f66 +086 CCCClient.exe CZ_Lib                334  +16 ExecuteSQL

Ist euch so etwas schon einmal untergekommen? Was würdet ihr tun, um das zu verhindern? Das Programm wird in einem Callcenter benutzt während wir mit den Anrufern sprechen. Solche Hänger kommen mehrfach täglich vor. Ist natürlich ungünstig, wenn das mitten im Gespräch passiert...

[mkinzler]

Warum Append?
Besser Query.SQL.Text direkt setzen.

[RSE]

Korrekt! Hilft aber leider nicht bei der Problemlösung. Ich werde es trotzdem ändern.

[neo4a]

Weise Deinem Query eine explizite TIB_Transaction zu.

[RSE]

@neo4a:
Kannst du mich zu den Hintergründen deines Lösungsansatzes aufklären?

Soweit ich weiß, startet IBO eine Standardtransaktion, die überall verwendet wird, wo nicht explizit eine andere Transaktion angegeben wird. Aktuell verwenden wir nur diese Standardtransaktion und nutzen das AutoCommit-Feature von TIBODatabase. Die im ersten Post zitierte Prozedur wird immer dann verwendet, wenn ein SQL-Statement (kann auch eine Abfrage sein) nur an einer Stelle benötigt wird und sich somit keine eigene Query etc. im DM lohnt. Momentan bekommen wir damit den Stand der DB von all dem, was mittels Query.Post bestätigt wurde. Dieses Verhalten darf sich nicht ändern. Leider habe ich keine umfassenden Kenntnisse von Datenbanken, um die Auswirkungen einer eigenen Transaktion umfänglich abschätzen zu können. Ich kann mir aber z.B. vorstellen, dass das die Ausführungsgeschwindigkeit (merklich???) und evtl. Sichtbarkeiten von Änderungen beeinflusst. Letzteres darf wie gesagt nicht sein.

[neo4a]

In allen meinen AdHoc-Abfragen habe ich immer dieses Konstrukt verwendet:

Delphi-Quellcode:

  
aQuery := TIB_Query.Create(nil);
try
  with aQuery do 
  begin
    sql.text:=Format(' select acc_profil from t_lms_account where nr=%d for update ',[lms.accountnr]);
    ib_Connection  := dm.IB_TransactionDefault.IB_Connection;
    ib_transaction := dm.IB_TransactionDefault;
    open;
    Edit;
    FieldByName('acc_profil').AsString := aProfile.AsString;
    Post;
  end
finally
  aQuery.free;
end;

und bin damit einer frühen Empfehlung von Jason gefolgt. Im produktiven Einsatz seit 1998 ist bei mir der von Dir geschilderte Fehler nie aufgetreten.

Gleichwohl gibt es beim Einsatz von Firebird (meine Erfahrung bis V. 2.1) einige Fallstricke. Einer der Wesentlichen: Auf Server und Client muss immer die gleiche gds32.dll verwendet werden. Ich habe dazu diese Datei in das Programm-Verzeichnis gelegt, damit sie nicht durch andere Installationen überschrieben wird (da gab's mal z.B. eine populäre Telefon-CD). Damit sind einige "komische" Effekte aus der Anfangszeit verschwunden.

Zur Transaktion: Es gibt keinen Perfortmance-Verlust, da jede SQL-Abfrage ohnehin in einer Transaktion abläuft. Benutzt Du Isolation = tiCommitted, solltest Du auch kein Problem mit der Sichtbarkeit haben. IBO verwendet verschieden Timer, um Deadlocks zu lösen. Ich denke, dass bei Dir dieser Fall auftritt. Man sollte z.B. in jedem Formular, eine eigene Transaktions-Komponente verwenden.

Error-Handling: Habe ich zentral auf IB_Connection.OnError abgearbeitet und nicht pro Query.