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

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

[RSE]

Zitat von neo4a:

Manchmal kostet Arbeit eben auch Geld.

Ich glaube in dem Fall kostet es uns mehr Geld die Arbeit nicht zu investieren, aber bis diese Erkenntnis durchsickert und was bewegt wird, vergeht viel Zeit...

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.

Das ist wohl wahr. Aber dass ihr nicht grundsätzlich sagt, dass es nicht gehen kann, motiviert mich dazu, es zu versuchen.

Update
Die Abfrage funktioniert übrigens im Test erwartungsgemäß reibungslos, auch wenn ich mit einem anderen Tool eine offene Transaktion habe.

[neo4a]

Zitat von RSE:

motiviert mich dazu, es zu versuchen.

Das hast Du falsch völlig verstanden.

Mach doch einmal folgendes:

Setze Dir eine VMWare-Umgebung auf mit mindestens 2 Instanzen.

In einer VM-Instanz installieren Dir Dein Unix mit dem Interbase-Server. Ist auch eine schöne Übung für den Ernst-Not-Fehler-Fall.

In der 2. VM- Instanz laufen so viele Clients wie möglich.

Modifiziere Dein Client- Programm mit einem Timer mit Random-Intervall, der die unterschiedlichen Lookup-Queries permanent feuert. Überprüfe visuell oder programmtechnisch, ob die Clients nun einfrieren.

Wenn das Einfrieren klappt: Gut, dann ist das Problem im Labor reproduzierbar. Wenn nicht, dann lasse Deine VM-Clients in einer Arbeitspause (arbeiten CallCenter auch nachts?) auf den realen Server los. Kommt es dann zum Einfrieren, dann liegts am IB-Server oder der Netzwerkumgebung (Switch, Firewall etc.).

Die Virtualisierung kostet nichts als Arbeit und hilft Dir, Dein Szenario systematisch zu isolieren. Weniger Voodoo, mehr Ergebnisse.

[RSE]

Zitat von neo4a:

Weniger Voodoo, mehr Ergebnisse.

Und erheblich mehr Aufwand und deshalb nicht vertretbar. Mit verhältnismäßig wenig Aufwand werde ich jetzt die besagte gds32.dll von 2004 testen. Entweder es bringt was oder nicht. Wenn nicht, dann müssen wir damit leben und haben einen Grund mehr, den Umstieg auf Firebird voranzutreiben. Ich habe schon mehr als einen halben Tag da reingesteckt, mehr als genug Arbeit. Jetzt probier ich also noch etwas Voodoo und dann hat sich die Sache erledigt (entweder zum Guten oder ohne Ergebnis).

Ich werde nächste oder übernächste Woche berichten, was bei dem Voodoo rausgekommen ist.

[RSE]

Es deutet alles darauf hin, dass die gds32.dll von 2004 scheinbar funktioniert, dabei aber die Datenbankdatei zerschießt. Zum Glück habe ich sie nur mit der Testdatenbank benutzt...