unbekanntes Speicherleck (BDE / MS-SQL)

[Bernhard Geyer]

Zitat von PT_Spawn:

Die BDE würde ich auch nicht freiwillig nutzen... leider gehört das zur Anforderung an das Zielsystem...

Wann wurden diese Anforderungen aufgestellt? 1840?

Zitat von PT_Spawn:

Wenn ich das nun garnicht in den Griff bekomme, dann werde ich zwangsläufig alles mit ADO programmieren...

Mach dich lieber mit ADO bekannt. Für MS SQL-Server sollte man unter Win32 nichts anderes nehmen.

[hoika]

Hallo,

- try finally benutzen

- das First nach dem Open kann weg

- mit memcheck mal prüfen, wo das Leck ist
oder zumindestens, dass nicht an deinem Programm liegt

- Prepare / UnPrepare direkt benutzen
(es gab mal nen Bug)

Ausserdem ist das hier komisch:
Result := Format('(SELECT MIN(PK_TProjekt) FROM TeilProjekte WHERE ProjektNummer=%s AND Bereich=%s)',
[VerifyData(DBCheckQuery.Fields[0]), VerifyData(DBCheckQuery.Fields[1])]);
DBCheckQuery.Close;

Du rufst dein VerifyData nochmal auf, ohne die Query vorher zu schliessen.


Ansonstens eh immer
- Unidirectional=True für die Query setzen,
sonst puffert die Bde alles zwischen
dann geht aber kein "Last", habe ich aber auch nicht gesehen



Ich würde sogar soweit gehen,
die Query hier lokal zu erzeugen.
Vergleichen mit der Netzlast, die erzeugt wird,
merkt man das überhaupt nicht.


Zu den Parametern:

Delphi-Quellcode:

with DBCheckQuery do
begin
  SQL.Clear;
  SQL.Add('SELECT MIN(PK_TProjekt) FROM TagesLeistungen ');
  SQL.Add('WHERE PK_TagLeistung = :PK_TagLeistung');
  ParamByName('PK_TagLeistung').AsString:= DBQueryArchive.Fields[0].AsString; 
end;

Das DBQueryArchive.Fields[0].AsString würde ich über einen Parameter
(der Funktion) übergeben.

Der Vorteil ist die bessere Lesbarkeit.
Ausserdem landet so eine Query im Query-Cache der Datenbank,
muss also nicht jedesmal neu vom SQL-Server übersetzt werden.
Das ist zumindestens bei Oracle und mssql 2005 so (ob der 2000er das schon kann ???)



Heiko