ADOquery nimmt viel RAM-Speicher weg, hilfe!!!!!!!!!!

[khalilazzz]

hallo zusammen
ich habe folgendes Problem:
ich möchte aus einem localen Access Tabelle mit 150000 Datensätze den MaximalWert eines ID herausfinden:
so sieht meine SQL-Anfrage,die durch einen ADOquery durchgefürht wird:

Delphi-Quellcode:

Select Max(ID)+1 as NewID from MyTabelle

nachdem ich den maximalen ID finde,schliesse ich den ADOquery (

Delphi-Quellcode:

MyADOquery.Active:=false oder MyADOquery.Close

),das Problem liegt dran dass ich mein Programm Ohne das Ausführen des Obengenannten Befehl ca 8 Mb RAM speicher benötigt.nachdem ich myadoquery aktiviere nimmt meine Programm ca 25 MB RAM speicher,auch wenn ich mein ADOquery schliesse,nimmmt immer mein Programm einen RAM-Speicher von 25 MB.
wie kann ich denn dieses Problem lösen,indem ich nach dem Schliesse meines ADOyquery dass meine Programm auf seine ursprüngiche RAM Speicher von 8 MB zurückkehrt?

Danke im Voraus

[Bernhard Geyer]

1, Welchen Speicherangabe hat 8 MB? Speicherauslastung, Virtueller Speicher, Maximale Speicherauslastung

2, Hast Du auch die entsprechende Connection wieder geschlossen?

[khalilazzz]

hi
die 8 MB bzw 25 MB speicher ist der speicher,die im Taksmanager->Prozesse von dem Programm im Anspruch genommen wird. (und nicht der speicher auf festeplatte)
man kann die connection nicht schliessen weil andere Programme damit verbunden bleiben.

MFG

[Bernhard Geyer]

Zitat:

Zitat von khalilazzz

hi
die 8 MB bzw 25 MB speicher ist der speicher,die im Taksmanager->Prozesse von dem Programm im Anspruch genommen wird.

Und welcher davon (Titel der Spalte)? Im Taskmanager kann über den Menu "Ansicht/Spalten auswählen..." definiert werden, welche Spalten angezeigt werden.

[khalilazzz]

ich habe es gerade nachgeprüft,das ist die speicherauslastung
im Taskmanger->Prozesse in der Spalte Speicherauslastung


MFG

[Bernhard Geyer]

Was passiert wenn die Aktion mehrmals durchgeführt wird.
Ich vermute das die Jet-Engine hier den Speicher verbraucht und man da vermutlich wenig machen kann.

[khalilazzz]

gibt es die möglichkeit dass man den Access datenbank mit einem anderen ersetzen kann,wobei dabei man die möglichkeit dass SQL-Anweisungen nicht im quellcode enthalten sonder dass man sie in dem datenbank als gespeicherte prozedur aufruffen kann?. (es muss keine MS-Server sein)

MFG

[trifid]

ist ein Index auf der Spalter ID :?: (Stichwort: PrimaryKey)
Hast du die gleichen Probleme wenn du

SQL-Code:

SELECT TOP 1 ID
FROM MyTable
ORDER BY ID DESC

ausführst :?:

Verwende besser das ADOdataset

Welche Jet-Engine (Version) verwendest du, und welche MDAC ist installiert :?:

Kannst du das ADOquery/ADOdataset zur Laufzeit erzeugen, SQL ausführen und dann das Objekt wieder freigeben :?:

[berens]

*bump*

Also ich stehe im Moment vor genau dem gleichen Problem; leider hat hier bisher noch keiner eine Lösung gepostet.

trifid: PrimaryKey ist vorhanden. MDAC sind die neuesten. BDS2006.

Das TAdoQuery wird zur Laufzeit erzeugt und auch ordnungsgemäß wieder freigegeben.
Database_CreateQuery ist eine Prozedur, die mir ein TAdoQuery erzeugt, Prepared auf True setzt und Datenbank zuweist etc.
LogToFile speichert mir den Parameter in eine Datei + den kompletten, im System verfügbaren Arbeitsspeicher.
Man beachte, dass ich hier wirklich nur -zu Testzwecken- q.Open und dannach direkt q.Close aufrufe. Die Daten aus der Datenbank werden also nicht in irgendwelchen Arrays etc. gespeichert!

Delphi-Quellcode:

  if assigned(Database) then begin
    q := NIL;
    LogToFile('TThumblist.Reload.Database_CreateQuery');
    Database_CreateQuery(q, Database);
    try
      LogToFile('TThumblist.Reload.q.SQL.Add');
//      q.SQL.Add('SELECT * FROM T_Storage_Thumbs ORDER BY strDescription');
      q.SQL.Add('SELECT TOP 10 * FROM T_Storage_Thumbs ORDER BY strDescription');
//      q.SQL.Add('SELECT TOP 1 * FROM T_Termin');

      LogToFile('TThumblist.Reload.q.SQL.Open');
      q.Open;
      LogToFile('TThumblist.Reload.q.Close');
      q.Close;
      LogToFile('TThumblist.Reload.Ende');
    finally
      FreeAndNil(q);
      LogToFile('TThumblist.Reload.Free');
    end;

Ergebnisdatei des Logs:

Zitat:

09:58: TThumblist.Reload.Start [Ram: 502.275]
09:58: TThumblist.Reload.Database_CreateQuery [Ram: 502.275]
09:58: TThumblist.Reload.q.SQL.Add [Ram: 502.275]
09:58: TThumblist.Reload.q.SQL.Open [Ram: 502.284] // <-- nach dem Ausführen von Open fehlen hier 27 MB
09:58: TThumblist.Reload.q.SQL.First [Ram: 475.561]
09:58: TThumblist.Reload.q.Close [Ram: 475.561]
09:58: TThumblist.Reload.Ende [Ram: 489.940]
09:58: TThumblist.Reload.Free [Ram: 489.940] // <-- es fehlen immernoch knapp 12 MB

Das Interessante:
Das Problem scheint nur aufzutreten, sobald eine Tabelle mit Blob-Feldern verwendet wird. Die Fehler werden wohl alle geladen und nicht wieder entladen, denn wenn ich SELECT TOP x * FROM T_Storage_Thumbs ausführe, ist der "fehlende" Arbeitsspeicher immer ein vielfaches größer als x.

Bin für Tips sehr dankbar...

Siehe auch: http://coding.derkeiler.com/Archive/...3-11/0560.html
Auch das in der Borland QC Berichtete Problem mit angeblichem Fix bringt keine Lösung http://qc.borland.com/wc/qcmain.aspx?d=3635 (man muss angemeldet sein, um die Datei von QC herunterladen zu können)

[berens]

In einer Newsgroup ( http://groups.google.ru/group/borlan...796b7e06282e87 ) bin ich auf das folgende Problem gestoßen:

Interessant dabei ist, dass das, was hier hier, als Bugfix für Delphi7 herausgegeben wurde. Komischerweise stand es in meiner AdoDB von BDS2006 wieder genauso drinnen (also erst inherited Destroy, dann die anderen Befehle).

Delphi-Quellcode:

destructor TADOCommand.Destroy;
begin
// we modified like this ==>
  Connection := nil;
  FCommandObject := nil;
  FreeAndNil(FParameters);
// we modified : end

  inherited Destroy;

{ // this is the original source code
 Connection := nil;
  FCommandObject := nil;
  FreeAndNil(FParameters);}
end;

destructor TADOQuery.Destroy;
begin
// we modified like this ==>
  FreeAndNil(FSQL);
// we modified : end

  inherited Destroy;
//  FreeAndNil(FSQL); // original source code
end;

Der Effekt lässt sich übrigens auch mit einer TAdoTable nachstellen:

Delphi-Quellcode:

  LogToFile('TThumblist.Reload.Start');
  if assigned(Database) then begin
    try
      at := TADOTable.Create(NIL);
      at.Connection := Database;
      at.TableName := 'T_Storage_Thumbs';
      at.CursorType := ctOpenForwardOnly;
      LogToFile('TThumblist.Reload.at.Open');
      at.Open;
      LogToFile('TThumblist.Reload.at.First');
      at.First;

      LogToFile('TThumblist.Reload.at.Close');
      at.Close;
    finally
      FreeAndNil(at);
    end;
  end;
  LogToFile('TThumblist.Reload.Ende');

Zitat:

10:49: TThumblist.Reload.Start [Ram: 488.891]
10:49: TThumblist.Reload.at.Open [Ram: 488.891]
10:49: TThumblist.Reload.at.First [Ram: 461.158]
10:49: TThumblist.Reload.at.Close [Ram: 461.158]
10:49: TThumblist.Reload.Ende [Ram: 475.536] // <-- hier fehlen auch 13 MB Ram