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...
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:
- Die Abfragen im Programm, die den Fehler verursachen sind simple SELECT-Abfragen, keine Updates etc.
- 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.
"Seit er seinen neuen Computer hat, löst er alle seine Probleme, die er vorher nicht hatte."