ADO-Funktion beendet nicht

[Masika]

Hallo,

ich habe folgendes Phänomen: Ich habe einen Thread gemacht für den Zugriff auf eine Oracle-Datenbank über ADO. Dieser Thread bleibt von Zeit zu Zeit (alle paar Tage) einfach stehen (Überwachungfunktion sagt mir, wann der zuletzt etwas getan hat). Keine Exception, nichts im Eventviewer. Da habe ich Statusfunktionen in die Prozeduren eingebaut und jetzt weiß ich auch, wo der (meistens) stehenbleibt:
in TADOQuery.Active := true.

Die fragliche Routine poste ich mal:

Delphi-Quellcode:

function TOracleAccess.Select(SQLStr: string; var RecCount: integer; var Rec: Variant): boolean ;
var
  SQL_Query: TADOQuery ;
  Row, Col, ColCount: integer ;
begin
  FProzedurName := 'Selectanweisung' ;
  FSubStatus := 'gestartet.' ;
  result := false ;
  EnterCriticalSection(FCritSect) ;
    if CheckConnection() then
    begin
      FSubStatus := 'Schritt 1' ;
      SQL_Query := TADOQuery.Create(nil) ;
      SQL_Query.CommandTimeout := 20 ;
      SQL_Query.Active := false ;
      SQL_Query.Connection := FDatabase ;
      SQL_Query.SQL.Clear ;
      SQL_Query.SQL.Add(SQLStr) ;
      try
        FSubStatus := 'Schritt 2' ;
        FDatabase.BeginTrans() ;
        FSubStatus := 'Schritt 3' ;
        SQL_Query.Active := true ;
        FSubStatus := 'Schritt 4' ;
        SQL_Query.Open ;
        FSubStatus := 'Schritt 5' ;
        SQL_Query.Last ;
        FSubStatus := 'Schritt 6' ;
        Row := SQL_Query.RecordCount ;
        if (Reccount <= 0) or (RecCount > Row) then RecCount := Row ;
        if RecCount > 0 then
        begin
          FSubStatus := 'Schritt 7' ;
          ColCount := SQL_Query.FieldCount ;
          Rec := VarArrayCreate([0, RecCount, 1, ColCount], varVariant) ;
          for Col := 1 to ColCount do
            Rec[0,Col] := SQL_Query.Fields[Col-1].FieldName ;
          SQL_Query.First ;
          Row := 1 ;
          while (not SQL_Query.Eof) and (Row <= RecCount) do
          begin
            for Col := 1 to ColCount do
            begin
              case SQL_Query.Fields[Col-1].DataType of
                ftInteger : Rec[Row, Col] := SQL_Query.Fields[Col-1].AsInteger ;
                ftString  : Rec[Row, Col] := SQL_Query.Fields[Col-1].AsString ;
                ftDateTime: Rec[Row, Col] := SQL_Query.Fields[Col-1].AsDateTime ;
                ftBCD     : Rec[Row, Col] := SQL_Query.Fields[Col-1].AsInteger ;
                ftFloat   : Rec[Row, Col] := SQL_Query.Fields[Col-1].AsFloat ;
              end ;
            end ;
            SQL_Query.Next() ;
            Inc(Row) ;
          end ;
          FSubStatus := 'Schritt 8' ;
        end ;
        FDatabase.CommitTrans ;
        result := true ;
        FSubStatus := 'Schritt 9' ;
      except
        Rollback ;
      end ;
      SQL_Query.Active := false ;
      SQL_Query.Free() ;
    end ;
  LeaveCriticalSection(FCritSect) ;
  FSubStatus := 'beendet.' ;
end ;

Ich bekomme den Status "Schritt3" und es geht nicht weiter. Einmal ist er auch in TADOCommand.Execute stehengeblieben, aber Inserts sind in meiner Anwendung halt einfach seltener als Selects.

Hat jemand eine Idee?

Danke und Gruß.

[shmia]

Exceptions in Threads werden nicht vom globalen Application Objekt abgefangen und angezeigt
sondern gehen verloren, wenn man nichts dagegegen unternimmt.
Deshalb:

Delphi-Quellcode:

procedure TOracleAccess.Execute;
var
   s : string;
begin
   try
      InternalExecute;  // die bisherige procedure Execute wurde ausgelagert
   except
      on E:Exception do
      begin
         s := E.Classname+ ' - ' + E.message+#13#10; 
         StringToFile('C:\exception.log', s);
      end;
   end;
end;

[Masika]

Deswegen steht ja im except-Block ein Rollback (Subroutine, die auch den Rollback in einem Try-Except-Block hat) drin. Wenn zB die Datenbankverbindung einfach verloren geht oder so (hab mit Netzwerkkabel ziehen getestet und mit Server down und so) läuft der Thread einwandfrei weiter, versucht, ne neue Verbindung aufzubauen und solange das nicht klappt wird die Verbindung als nicht vorhanden angezeigt.

[Bernhard Geyer]

Welche ADO-Provider wird den verwendet? Doch hoffentlich nicht der MS Provider für Oracle?

[Masika]

oO

 ConnectionString := 'Provider=MSDAORA.1;Password=...' Welchen soll ich nehmen stattdessen?

Vielen Dank im Voraus.

[Bernhard Geyer]

Zitat von Masika:

 ConnectionString := 'Provider=MSDAORA.1;Password=...' Welchen soll ich nehmen stattdessen?

Entweder besorgst Du dir einen Provider bei Oracle direkt oder nimmst z.B. ODAC.
Der MS-Provider ist 'ne Machbarkeitsstudie und absolut nicht zu gebrauchen!
MS wollte nur zeigen das man auch über ADO auf Oracle zugreifen könnte. Aber die Aufgabe war nicht einen funktionsfähigen halbwegs fehlerfreien Provider zu entwickeln.

[Masika]

Wenn ich den von Oracle nehmen will, was muss ich dann im Connection-String eintragen? Ich finde das auf der Oracle-Seite nicht.

Danke.

[Bernhard Geyer]

Zitat von Masika:

Wenn ich den von Oracle nehmen will, was muss ich dann im Connection-String eintragen? Ich finde das auf der Oracle-Seite nicht.

Frag mich was leichteres. Bie Oracle was zu finden ist wie die suche nach der Nadel im Heuhaufen.
Vor allem da ich dir eher native Zugriffskomponenten wie von CoreLabe empfehle. Damit kommt du z.B. u.U. komplett um eine Oracle NET8-Installation herum. Haben die MySQL-Komponenten vom gleichen Hersteller im Einsatz und sind sehr zufrieden damit.

[Masika]

Ich habe inzwischen mit dem Oracle-Treiber probiert. Das Verhalten hat sich leider nicht geändert.
Es ist immer noch so, dass der Aufruf teilweise nicht beendet wird (relativ selten, ungefähr einmal die Woche bei nem Programm, das 24 Stunden am Tag 7 Tage die Woche sekündlich auf die DB pollt).

Hat vielleicht noch jemand eine andere Idee? Hat noch jemand das Problem?

Kann es ein Problem sein, dass ich den Oracle 9i Client installiert habe und die Datenbank Oracle10 ist? Angeblich sind die ja voll kompatibel.

Danke im Voraus und Gruß...

[Bernhard Geyer]

Zitat von Masika:

Kann es ein Problem sein, dass ich den Oracle 9i Client installiert habe und die Datenbank Oracle10 ist? Angeblich sind die ja voll kompatibel.

Oracle und 100%ige Kompatiblität - selten so gelacht.
Bei Oracle kann dir 3stelle im vierten Abschnitt der Versionsnummer über funktionieren/nicht funktionieren entscheiden.

Bei solche hohen Abfragerhythmus würde ich mal mit FastMM/AQTime kontrollieren ob evtl. in deinem Programm Speicher/Ressourcenlücken auftreten die nach größerer Laufzeit zuschlagen.