Announcement

Collapse
No announcement yet.

Threads mit ADO und Oracle

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Threads mit ADO und Oracle

    Ein Programm muss für Kunden Abrechnungsdaten aus Dbase-Tabellen auslesen, vergleichen und diese dann in eine Oracle DB (Ver. 8.1) wegschreiben. Da die Anwendung zeitkritisch ist, habe ich zwei Threads definiert die zwei der Tabellen abarbeiten sollen.<br>Alles lief gut bis die Kundenanzahl immer grösser wurde. Ich stelle fest, das der RAM pro verarb. Kunde um ca. 250 Kb erhöht wurde, was dann irgendwann zum Exodus führt. Die Threads werden pro Kunde neu anglegt... <p>
    TScanThread = class(TThread): <br>
    private<br>
    FQuery : TADOQuery;<br>
    FTable : TTable;<br>
    FCustNo : string;<br>
    procedure FillBacklog;<br>
    ...<br>
    constructor TScanThread.Create(Query: TADOQuery; Table: TTable; CustNo: string);<br>
    begin<br>
    inherited Create(False);<br>
    FCustNo := CustNo;<br>
    FQuery := Query;<br>
    FTable := Table;<br>
    FreeOnTerminate := True;<br>
    end;<p>
    ... erfüllen ihre Aufgabe, und werden über - FScanThread.Free; - wieder freigegeben. Die Frage lautet nun, wo wird Speicher belegt bzw. wie bekomme ich ihn wieder. Jeder Thread hat seine eig. ADO-Con. über OLE-DB. Für Hilfe wäre ich sehr dankbar<br> mfg Rainer Schmidt

  • #2
    Hallo,

    wenn die Datenmenge der SELECT-Abfrage nur zeilenweise abgearbeitet wird, sollte <b>ctOpenForwardOnly</b> für die Eigenschaft CursorType aktiviert werden. In diesem Fall muss ADO keine lokalen Datensatzpuffer vorsehen, der alle bisher eingelesen Datensätze zwischenspeichert

    Comment


    • #3
      Hallo Herr Kosch,<p>
      Vielen Dank für Ihren Rat, leider hat sich die Situation nicht wesentlich verändert. Es werden nach der Cursorumstellung nur noch 30% des allokierten Speichers einbehalten (ca. 8Kb).<br> Mir ist leider ein Fehler bei der Beschreibung des Problems unterlaufen:<br>Die Flussrichtung der Daten bewegt sich von Oracle auf div. Dbase-Tables. Vielleicht ergibt sich aus diesem Umstand eine andere Betrachtungsweise, die unserem Problem Abhilfe verschaffen könnte. Die CursorLocation ist <b>clUseClient</b> da wir mit .Locate arbeiten.<br>mfg Rainer Schmid

      Comment


      • #4
        Hallo,

        wie sieht die Implementierung in der TThread-Methode <b>Execute</b> aus? Werden dort alle Interface-Zeiger auf die ADO-Objekte wieder freigeben bzw. alle Verbindung (TADOConnection) wieder korrekt getrennt?. Die Beschreibung des Problems hört sich so an, als ob je Kunde eine Objektinstanz vom RecordSet-Objekt im Speicher bleibt

        Comment


        • #5
          Hallo Herr Kosch,<p>
          durch Ihre Bemerkung bezüglich der TADOConnection wurde ich darauf aufmerksam das ich diese nicht korrekt beendete und sich so Ihre Vermutung bestätigt hat.<br>Nachdem ich jetzt die TADOCon. sauber verwalte hat sich das Problem aufgelöst.<br>mfg R. Schmid

          Comment

          Working...
          X