Funktion mit TQuery als Rückgabewert

[bogdan]

Ich benutze die Zeos Komponenten für SQL Abfragen.

SQL Statement soll in einer Funktion ausgeführt und das Ergebnis als TQuery weiter gegeben werden.

Also so in etwa:

Delphi-Quellcode:

function SQLSelect(SQLtxt: String):TZReadOnlyQuery;
var xQuery : TZReadOnlyQuery;
begin
  xQuery := TZReadOnlyQuery.Create(nil);
  xQuery.Connection := ZConnection1;
  xQuery.SQL.Clear;
  xQuery.SQL.Add(SQLtxt);
  if ZConnection1.Connected then
  begin
    xQuery.Open;
    xQuery.Active := True;
  end else ShowMessage('Keine Datenbankverbindung!');
  Result := xQuery;
end;

So bläht sich aber das Query mit jeder neuen SQL Abfrage auf und dann ist der Speicher voll.
Das Aufblähen könnte ich mit

Delphi-Quellcode:

FreeAndNil(xQuery);

am Ende der Funktion beheben.

Das Problem ist nur: der Rückgabewert ist dann auch immer leer.

Array, Strings, etc. als Rückgabewert wollte ich eigentlich nicht nutzen, da die Daten dann nochmal aus der Query in das Array, etc. geschrieben werden müssen. Ist doch irgendwie doppelt-gemoppelt.

[Bernhard Geyer]

Irgend jemand muss halt die Queries wieder aufräumen/freigeben.
Bei deinem Ansatz wäre es die aufrufende Funktion/Methode.

Hier wäre es aber günstig wenn der Funktionsname darauf hinweist das eine Objekt/Instanz erzeugt wird die man als Aufrufender auch wieder aufräumen muss.
Also z.B. CreateQueryBySQL(...)

[sx2008]

Was spricht dagegen ein Datenmodul zu nehmen und darauf so viele verschiedene Queries zu platzieren wie du brauchst?
Dynamisch erzeugte Queries benötigt man nur in Sonderfällen.
Und selbst dann kann man das gleiche Query-Objekt immer wieder benützen (mit jeweils anderem SQL-Text).

[mschaefer]

Wenn man den obigen Vorschlag mit dem Datamodul nimmt, dann könnte man eine procedure mit den Rückgabewerten "SQL_String", "Active", "ReadOnly" nehmen. Das sollte auch flotter Laufen, als das Objekt Auf- und Abbauen.

Grüße in die Runde // Martin

[Furtbichler]

Zitat:

Zitat von sx2008 (Beitrag 1234360)

Und selbst dann kann man das gleiche Query-Objekt immer wieder benützen (mit jeweils anderem SQL-Text).

Zur Informationsbeschaffung ja, zur Anzeige nur bedingt. Da muss man sich dann etwas anderes einfallen lassen (TClientDataset z.B.)

Zitat:

Zitat von mschaefer (Beitrag 1234362)

Wenn man den obigen Vorschlag mit dem Datamodul nimmt, dann könnte man eine procedure mit den Rückgabewerten "SQL_String", "Active", "ReadOnly" nehmen. Das sollte auch flotter Laufen, als das Objekt Auf- und Abbauen.

Die Sache mit den Rückgabewerten könntest Du bitte dann doch etwas näher erläutern. Und wie langsam ist eigentlich das Instantiieren und Freigeben einer Query in etwa? Kannst Du das mal ausmessen (z.B. 100000 mal Create/Free)? Danke.

[Sir Rufo]

Das Erzeugen einer Query-Instanz geht sehr flott und macht kaum einen Unterschied ob wiederverwendet oder neu erzeugt.

Bei einer Connection sieht das anders aus, weil ja jedes Mal die Verbindung neu aufgebaut werden muss.

Hier wäre mE auch der Vorschlag mit dem TClientDataset am sinnvollsten.