Firebird hängt beim disconnect

[danielA]

Hallo erstmal.

Ich habe das Problem das Firebird (1.0.3) sich gelegentlich beim schließen meiner Anwendung aufhängt. Diese Anwendung nimmt die Datenbank notwendigerweise etwas härter ran. Das heißt es werden in einer Stored Proc momentan bis zu 5000 Datensätze in eine andere Tabelle kopiert (ist eine Meßreihe) um berechnungen in akzeptabler Zeit darauf ausführen zu können.
UDFs habe ich alle schon wieder rausgeschmissen, so daß es daran nicht liegen kann. In der Log des Firebird Servers taucht dann folgender Fehler auf

"INET/inet_error: read errno = 10054"

Das weißt laut IBPhoenix auf einen Netzwerkfehler hin aber auf Localhost ?
Habe das nun schon auf mehreren Rechnern ausprobiert auf jedem dieses Phänomen (übrigens auch mit IB 6.0.1). Sobald ich das Programm schließe bleibt das Programm beim Connected:=false in der OnClose, gelegentlich hängen. Transactionen wurden an diese Stelle alle schon beendet. CPU-Last 0%. Es kann dann bis zu 10 min dauern bis er sich gefangen hat, je nachdem wieviel ich berechnen lassen habe. Breche ich den Task meines Programmes hart ab hilft nur noch ein Neustart des Rechners. Kann es an den Standard Delphikomponenten liegen die für Interbase bei Delphi 6 dabei sind ? Ich arbeite auch fast ausschließlich mit CommitRetaining um die Transaktionen offen zu halten. Kann es vielleicht auch daran liegen ? Währe echt toll wenn mir hier jemand helfen könnte, habe echt keine Idee mehr.

Gruß Daniel

[mschaefer]

Moin, moin Daniel,

probier mals die Transaktion zu schließen. Kommt dann ein Fehler? Könne es sein, das Deine
Stored Procedure noch läuft oder das Ergebnis nicht gespeichert hat?
Dann dürfte die Transaktion nicht beendet werden können.

Die Delphi-Komponenten sind da eher unkritisch. Ebenso ZEOS, denn normnalerweise kann man
PDB-Programme damit spontan bbenden, wenn dabei die Database-Conntection gelöst wird.


Grüße // Martin

[Hansa]

Ich glaube kaum, daß der Rechner hängt, der wird nur unendlich langsam. Und zwar weil er 5000 Transaktionen rückwärts abarbeiten muß. Mache mal nach dedem 100. oder 500. ein Commit. Wetten, daß es dann geht ? Aber ohne Gewähr. 8)

[danielA]

Hallo,

erstmal danke für die schnellen antworten.
Also die Transaktionen sind wirklich alle beendet hier mal ein Teil aus der OnClose:

Delphi-Quellcode:

        ...
Dm1.IbTransaction1.Commit;
Dm1.IbTransaction1.Active:=false;
Dm1.IBDatabase1.Connected := False;  // << und hier bleibt er dann hängen
        ...

Das mit dem Commit ist denke ich eine Gute Idee nur werden die Datensätze in einer Stored Proc auf einmal kopiert also in der Art:

Delphi-Quellcode:

For select ... do
Begin
  insert into  ...
END

und Transaktionen kann man ja in Stored Procedures nicht beenden.
Da werde ich mich mal mit Limit, was ja für Firebird neu sein soll, auseinandersetzen müssen.

Gruß und Danke

Daniel

[Udontknow]

Was für eine Transaktions-Isolation nutzt du? Das kann sich u.U. auf die Performance auswirken.
Wechsel doch mal auf den FB 1.5! Hat sich schliesslich schon einiges getan...

Cu,
Udontknow

[danielA]

Hallo,

also meine Transaktionseigenschaft ist auf Schnappschuß (also concurrency nowait) eingestellt.
Habe meine Stored Proc mal so umgeschrieben, daß er nur 200 Datensätze kopiert und die letzte kopierte ID zurückgibt. Durch anschließendes Commit und erneutem Aufruf der Stored Proc erhoffe ich mir, daß es funzt. Hat beim ersten Test ebend leider noch nicht funktioniert. GFIX hat mir aber auch Indexfehler gemeldet in genau den Tabellen, welche von der Stored Proc angefaßt werden.
Firebird 1.5 habe ich vor der 1.0.3 schon ausprobiert aber da kamen immer Fehler wenn ich mehrere Select Statements kurz hintereinder aufgerufen habe in der ORDER BY Clausel. Wenn ich die Statements einzeln ausgeführt habe (aus meinem Programm) haben sie jedoch immer Funktioniert.

Gruß Daniel

[Udontknow]

Zitat von danielA:

Firebird 1.5 habe ich vor der 1.0.3 schon ausprobiert aber da kamen immer Fehler wenn ich mehrere Select Statements kurz hintereinder aufgerufen habe in der ORDER BY Clausel. Wenn ich die Statements einzeln ausgeführt habe (aus meinem Programm) haben sie jedoch immer Funktioniert.

Merkwürdig. An FB liegt das meiner Meinung nach nicht, bei uns in der Firma nutzen wir FB 1.5 mit relativ großen Datenbanken (>4 GB); so ein Fehler trat aber noch nie auf. Allerdings nutzen wir auch DBExpress.

Cu,
Udontknow

[danielA]

Habe die TIBQuery abgeleitet. Folgender Code funktioniert unter IB6 und Firebird 1.0.3. Bei Firebird 1.5 fliegt er an der markierten Stelle raus wenn
UseCountStatement True ist (und FDBType auf F_Interbase6 steht).
PS.: Ich weiß das das Countstatement bei Firebird nicht mehr notwendig ist da RecordCount richtig gesetzt wird. Leider ist das nur eine Stelle an der er mit dieser Fehlermeldung rausfliegt.

Delphi-Quellcode:

   
   ...
        Self.Active:=False;
        if (MyUseCountStatement) and (FDBType = F_Interbase6) then
        begin
          SQLKompo:=TIBQuery.Create(self);
          SQLTransaction:=TIBTransaction.Create(self);
          try
            SQLTransaction.DefaultDatabase:=Self.Database;
            SQLKompo.Database:=Self.Database;
            SQLKompo.Transaction:=SQLTransaction;
            if not SQLKompo.Transaction.InTransaction then
               SQLKompo.Transaction.StartTransaction;
            SQLKompo.SQL.Text:=CountStatement;
            SQLKompo.Prepare;
            SQLKompo.Active:=True;
            FRecordCount:=SQLKompo.fieldbyname('ANZAHL').AsInteger;
            SQLKompo.Transaction.Rollback;
            SQLKompo.Active:=False;
          finally
            SQLKompo.Free;
            SQLTransaction.Free;
          end;
        end;
        Self.SQL.Clear;
        Self.SQL.Add(Statement);
        Self.Prepare;
        Self.Active:=True;  //   <== und hier fliegt er dann raus
   ...

Gruß Daniel

[Udontknow]

Was für eine Fehlermeldung erhälst du denn genau?

Cu,
Udontknow

[danielA]

Hallo nochmal,

komme leider erst MMontag wieder an meine Quellen ran aber er meckert dann über das ORDER BY.
Nehme ich das ORDER BY raus funktioniert es wieder.

Gruß Daniel