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

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

[RSE]

@neo4a:
Danke für den ausführlichen Post! Da sind einige Lösungsansätze enthalten, die ich ab Montag mal der Reihe nach abarbeiten werde.

Zur Transaktion: Ich dachte an die Erstellung einer neuen Transaktion auf dem Server. Aber der Zeitbedarf dafür ist sicherlich wenn, dann nur im Hochleistungsbereich interessant.

Zitat von neo4a:

IBO verwendet verschieden Timer, um Deadlocks zu lösen.

Heißt das, wenn ich vor Query.Free lange genug warte, dann löst sich der Deadlock von selbst bzw. tritt nicht auf? Das werde ich mal probieren - besser lange warten als ewig warten.

Zitat von neo4a:

Man sollte z.B. in jedem Formular, eine eigene Transaktions-Komponente verwenden.

Im Moment haben wir gar keine... Ich weiß aber, dass IBO da im Hintergrund was macht. Werde mich am Montag nochmal genauer damit beschäftigen, wenn ich die Zeit finde.

IB_Connection.OnError werde ich mir dann auch mal zu Gemüte führen.


Jetzt wünsche ich allen erst mal ein schönes Woe, ich melde mich auf alle Fälle nächste Woche wieder, wenn es Neues gibt.

[RSE]

Ich habe die Versionen der gds32.dll überprüft. Hier alle Versionen der beteiligten Komponenten (falls was fehlt bitte nachfragen!):

• Delphi 5
• IBO Version 3.4.Ce (TIBODataBase, TIBOQuery)
• gds32.dll Version 6.0.1.0 (in System32 auf WinXP, keine gds32.dll im Programmverzeichnis)
• InterBase Server 6.1 auf Linux

Ich habe versucht, die tatsächlich zur Laufzeit geladene gds32.dll herauszubekommen und zu prüfen. Das schlägt leider fehl, weil IBO 3.4 noch kein TIB_SessionBase.GDS_Handle hat - das ist im Quelltext auskommentiert - und EnumProcessModules - zum Durchsuchen aller geladener dlls - ist in Delphi 5 offenbar noch nicht bekannt gewesen.
Wir benutzen TIBODataBase.Isolation = tiCommitted und TIBODataBase.AutoCommit = True. Gibt es da irgendwelche bekannten Versionskonflikte?

Bzgl. der Transactions steht in der Hilfe folgendes:

Zitat:

Here are some hints for working with IB Objects transactions:
With IBO three conceptual aspects of transaction need to be considered. They are the physical transaction, the logical transaction and whether the transaction is explicit. Each has its own behavior and in many cases the behaviors overlap. Other factors, such as isolation, also affect the behaviors.

Physical Transactions
· IBO automatically takes care of starting the physical transaction. It is not necessary to start the physical transaction explicitly yourself.
· It is the physical transaction which needs to be kept as short as possible so that the server is not prevented from doing its garbage collection.
· It is where the settings that provide the isolation, lockwait, recversion, and so on, take effect.
· The physical transaction forms the foundation for the logical and explicit transactions.

Long Transactions
A physical transaction of long duration can lead to severe performance degradation and, eventually, a server crash if it is left for more than a day or so in a moderately active database environment. A high-volume database could show signs of degradation within a day.

End of the Physical Transaction
A physical transaction is ended when Commit[Retaining], Rollback[Retaining], Refresh() or Close is called. The same methods also end a logical unit of work and an explicit transaction.

Oldest Active Transaction (OAT) Management
OAT (Oldest Active Transaction) Management is IBO's set of automated features that close the physical transaction for you. Provided you avoid or carefully manage the cases where the OAT management is suspended, you will not have any problems with long physical transactions in your applications.

Here are the cases that prevent IBO from automatically advancing the OAT:
1. You are not using cached updates, AutoCommit is false and you post any change to the database.
This flags the transaction as active (tsActive). The OAT stuff is suspended whilst a transaction's state is tsActive. You must call Commit[Retaining], Rollback[Retaining], LosePoint, SavePoint or Refresh() to resolve the active state of the transaction and allow the OAT stuff to resume.
2. You are using PessimisticLocking and you have a row in dssEdit state.
In order to give duration to the lock, the transaction must be held open. As soon as the row is posted or cancelled, the lock ends, the former rules apply and OAT behavior resumes.
3. You use the tiConcurrency isolation level.
OAT will not advance, because tiConcurrency tells the server that you want a snapshot view of the database. If physical transactions were to able to come and go in order to advance the OAT, the snapshot view would be corrupted. Each time a new transaction is started with tiConcurrency you get a fresh view of the database because other user's committed changes become visible.
4. You have a SELECT statement that will return thousands of rows and you open it but don't fetch all the records.
This forces a cursor to be held open on the server until all the rows have been fetched. Eventually this situation would be overcome by the background fetching that begins taking place in order to free up the cursor. If you set the CommitAction to caInvalidateCursor then it will just get refreshed for you and there won't be a problem.

It is generally inadvisable to leave large datasets open where all records are not fetched in.
Be sure to get familiar with the TimeOutProps settings because it is possible there to ensure that the OAT advancement issues can be dealt with.

Logical Transactions
Consider a logical transaction to be the unit of work that the user is performing. IBO will automatically keep track of your logical transaction for you.
Implicit Logical Transaction
Use the TransactionIsActive property to determine whether you are in an implicit logical transaction.
· If AutoCommit is true, the implicit logical transaction will be limited to the duration of time that any dataset is in an edit state. As soon as it is posted, the transaction is auto-committed and the implicit logical transaction ends.
· If AutoCommit is false then the implicit logical transaction will start from the moment at which a dataset is put into an edit state and will persist after a change is posted. It will not finish until the transaction is ended by explicitly calling one of the methods to end it.
· If a dataset is cancelled and no other changes had been posted then the implicit logical transaction will be ended automatically.

Explicit Transactions
· An explicit transaction is initiated by calling the StartTransaction method. It will persist until one of the methods to end the unit of work is called.
· LosePoint and SavePoint does not end an explicit transaction.
· The InTransaction property is used exclusively to determine whether you are in an explicit transaction. It does not indicate the status of an implicit logical transaction or of the underlying physical transaction.
· AutoCommit=True behavior is suspended during an explicit transaction and all changes posted to the server remain in the transaction, i.e. they are not committed when a dataset's Post method is called.

AutoCommit
· Setting AutoCommit to True allows you to avoid taking explicit control of logical transactions. It will generate an immediate SavePoint when you activate the transaction by posting a change to a dataset, executing a DML statement, etc. Everything becomes committed on the server the moment it is executed. In these conditions, there is no logical transaction to worry about.
· If AutoCommit is false, you need to call LosePoint, SavePoint, CommitRetaining, Commit, RollbackRetaining, Rollback or Refresh() in order to process a unit of work. These methods all end the logical transaction whether it is implicit or explicit.

In der Hilfe zu TIB_Database (Superklasse von TIBODatabase) steht folgendes:

Zitat:

In the case where a statement's or dataset's IB_Connection property is not a TIB_Database class, and its IB_Transaction property is left blank, it will create its own internal transaction. If you made the choice to avoid working with simultaneous transactions, this behavior could give rise to the undesirable effect of having different statements and datasets being kept within different transaction contexts.

Ich würde da jetzt mal reininterpretieren, dass für jede Query bei Bedarf automatisch eine eigene Transaktion angelegt wird (von Edit bis Post). Seht ihr das genauso?

Ich werde folgende Konstruktion ausprobieren, in der Hoffnung, dass der Vorschlag mit den IBO-Timern Erfolg bringt und der Konflikt intern in einem anderen IBO-Thread provoziert wird:

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;
    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);
        // Hoffen, dass sich das Aufhängen bei der Freigabe mittels WaitForMultipleObjects durch vorheriges Warten erledigt
        for i := 300 downto 0 do // sollte ein paar Sekunden entsprechen
          Sleep(0); // verwirft den Rest der Zeitscheibe
        raise; // Ausführung der Prozedur trotzdem abbrechen, Query freigeben
      end;
    end;
    try
      // Tue Was
    finally
      Query.Close;
    end;
  finally
    Query.Free;
  end;

[neo4a]

Server- und IBO-Version sind sehr alt. Ich kenne nicht Dein Budget, aber zumindest für den Server gibt es mit Firebird eine gute Alternative. Ich habe zu Zeiten von IBO 3.X mit Firebird 1.03 keine Probleme gehabt.

Das "Einfrieren" sieht mir - wie gesagt - ganz nach einem Deathlock aus. Du kannst dieses Verhalten recht leicht nachstellen, indem Du einen Datensatz mit einem SQL-Tool (z.B. IB_SQL) editierst und die Transaktion nicht beendest. Dann gehst Du mit Deiner App (sofern sie in dem Alter noch gehen kann) auf diesen Datensatz und tust, was Du tun willst. Überprüfe, ob da was einfriert.

Kannst Du so das Verhalten Deiner App reproduzieren, dann kann man Lösungen suchen, alles andere ist Mutmaßung und führt eigentlich zu nichts.

[RSE]

Zitat von neo4a:

Server- und IBO-Version sind sehr alt.

Da stimme ich völlig mit dir überein. Da das Programm aber noch viel schwerfälliger ist, als die DB-Version alt, und die Programmierkapazitäten (genau wie die im DB-Management) äußerst knapp sind, muss ich wohl noch ´ne Weile damit auskommen...

Zitat von neo4a:

Das "Einfrieren" sieht mir - wie gesagt - ganz nach einem Deathlock aus. Du kannst dieses Verhalten recht leicht nachstellen, indem Du einen Datensatz mit einem SQL-Tool (z.B. IB_SQL) editierst und die Transaktion nicht beendest. Dann gehst Du mit Deiner App (sofern sie in dem Alter noch gehen kann) auf diesen Datensatz und tust, was Du tun willst. Überprüfe, ob da was einfriert.

Kannst Du so das Verhalten Deiner App reproduzieren, dann kann man Lösungen suchen, alles andere ist Mutmaßung und führt eigentlich zu nichts.

Das ist eine Idee. Ich bin allerdings sehr skeptisch, ob das glücken wird, weil:

1. Die Abfragen im Programm, die den Fehler verursachen sind simple SELECT-Abfragen, keine Updates etc.
2. Wäre es ein Deadlock auf der DB aufgrund von Zugriffsbeschränkungen durch andere Transaktionen, dann sollte es trotzdem keine Zugriffsverletzung in Modul gds32.dll geben

Ich werde morgen berichten, was dabei herausgekommen ist.

Gehen wir mal davon aus, dass es sich tatsächlich um einen Bug in der DLL handelt. Wir setzen hier IBExpert ein. Dort gibt es eine gds32.dll von 2004 (Version 1.5.2.4731 für Firebird 1.5), die offenbar für die Verbindung zu unserem Interbase 6.1 verwendet wird, wenn ich die IBExpert-DB-Einstellungen richtig lese. Meinst du es ist eine gute Idee diese neuere dll testweise auf den Clients zu verwenden, auf denen unser Programm läuft? IBExpert läuft sehr stabil auf unserem IB 6.1 Server.

[neo4a]

Zitat von RSE:

die Programmierkapazitäten (genau wie die im DB-Management) äußerst knapp sind, muss ich wohl noch ´ne Weile damit auskommen...

Manchmal kostet Arbeit eben auch Geld.

Zitat von RSE:

Meinst du es ist eine gute Idee diese neuere dll testweise auf den Clients zu verwenden, auf denen unser Programm läuft? IBExpert läuft sehr stabil auf unserem IB 6.1 Server.

Dieses DB-Tool läuft im ständigen Multiuser- Zugriff?! Wie auch immer, ich habe es eigentlich nie gebraucht und kann nicht beurteilen, ob es so als Referenz taugt.

Wie gesagt, kannst Du den/die Fehler nicht nachstellen, sind alle Deine weiteren Versuche wie reines Voodoo: Du kannst nur hoffen, dass es hilft.

[Lemmy]

Hi,

Zitat von RSE:

die Programmierkapazitäten (genau wie die im DB-Management) äußerst knapp sind, muss ich wohl noch ´ne Weile damit auskommen...

Aber jede Menge Zeit so einen Fehler zu suchen ist vorhanden? Keine Angst, das soll jetzt kein Vorwurf sein, ich war selbst oft genug in dem Hamsterrad gefangen. Du musst relativ bald an den Punkt kommen wo Du das ganze stoppst und grundlegende Umbauten vornimmst. Die IB6-Firebird 1.5 Umstellung ist bei mir schon lange her, aber ich war der Meinung dass das noch relativ schmerzfrei geht, d.h. einfach IB deinstallieren FB installieren und gut ist (nicht vergessen die DB per Backup zwischen den Versionen zu verschieben). Wenn Du dann noch einen alternativen Server dafür nimmst, sollte der Zeitaufwand doch sehr überschaubar sein und wenn es nichts bringt kannst Du wieder auf IB6 zurück.

Zitat von neo4a:

Wie gesagt, kannst Du den/die Fehler nicht nachstellen, sind alle Deine weiteren Versuche wie reines Voodoo: Du kannst nur hoffen, dass es hilft.