Ergebnis eines ADOQuery zurückgeben

[slemke76]

Hallo zusammen,

ich habe eine Funktion "A" in einer Klasse gekapselt, die ein SQL-Query mit ADOQuery.Open ausführt. Ich möchte nun das Abfrageergebnis in die Hauptroutine zurückgeben um dann durch die Datensätze mit .First und .Next durchzugehen.

Die Frage ist nun, welchen Rückgabetyp ich für die Funktion verwenden soll; TAdoQuery wäre naheliegend; gibt es etwas "besseres" - wäre z.B. _Recordset ?

lg
Sebastian

[DeddyH]

Ich bin zwar im Allgemeinen kein Freund von Objekten als Funktionsrückgabe, aber wie wäre es mit TDataset?

[edit] :lol: Union :cheers: [/edit]

[Union]

Ich würde da auch TDataSet verwenden aber als Parameter. Ich hab sonst immer ein ungutes Gefühl bei der Freigabe.

[shmia]

Zitat:

Zitat von Union (Beitrag 1046394)

Ich würde da auch TDataSet verwenden aber als Parameter. Ich hab sonst immer ein ungutes Gefühl bei der Freigabe.

Das wird hier aber leider nicht funktionieren.
TDataset ist eine abstrakte Klasse. Man kann also nicht TDataset.Create aufrufen und das erzeugte Objekt übergeben.

Delphi-Quellcode:

procedure TDatenmodulXY.A(ds:TDataset);
begin
  // Geht nicht, weil TDataset das Property SQL nicht kennt
  ds.SQL.Text := 'SELECT * FROM ...';

  // die Daten von einer ADOQuery auf das Dataset zu kopieren geht auch nicht
     
end;

Also muss es halt doch eine Funktion sein:

Delphi-Quellcode:

function TDatenmodulXY.A:TDataset;
begin
  ADOQueryABC.close;
  ADOQueryABC.SQL.Text := ...; // evtl. auch weglassen und SQL zur Entwicklungszeit einstellen
  ADOQueryABC.Open;
  Result := ADOQueryABC;
end;

[Union]

Zitat:

TDataset ist eine abstrakte Klasse. Man kann also nicht TDataset.Create aufrufen und das erzeugte Objekt übergeben.

Dann muss man sich halt an der Objekthierarchie solange zum TAdoQuery runterhangeln bis man was passendes gefunden hat. Oder arbeitet fieserweise mit einem harten Typecast, wenn man weiss dass das eine TAdoQuery reinkommt.

[slemke76]

Hallo zusammen,

da habe ich ja richtig was losgetreten :-)

Ich bin trotzdem noch nicht so richtig weiter; ich erläutere noch mal ein wenig mehr, worum´s geht.

Die besagte Klasse, in der sich die Funktion für die SQL-Abfrage befindet, kapselt den Zugirff auf eine Datenbank eines Dritt-Softwareherstellers. In dem construct wird die ADOConnection und ADOQuery dynamisch erzeugt/created.

Die Hauptroutine soll im Anschluss an den Aufruf der Funktion "getSentItems" der Klasse das Rückgabeergebnis in eine CSV schreiben und ruft eine eigene, nicht in der Klasse enthaltene, Funktion auf:

Delphi-Quellcode:

  externalsoftware:=Texternalsoftware.Create();
  if (externalsoftware.connected) then begin
    Items:=externalsoftware.getSentItems();
    SaveToCSV(Items, <Dateiname>);
  end;
  externalsoftware.Free;

Wenn ich jetzt den Rückgabewert von getSentItems vom Typ TDataSet deklariere (TCustomADODataset ebenfalls schon getestet), sagt er mir in SaveToCSV "Operation bei geschlossener Datenmenge nicht ausführbar"; ein .Open geht auch nicht, weil die temporäre Tabelle, aus der die Daten stammen, am Ende von getSentItems gelöscht wird.

Im Prinzip ist das ja alles noch das Falsche - ich brauche ein Objekt, das nur die Ergebnismenge aufnimmt, aber keinerlei Verbindungsdaten o.ä. und hatte gehofft, daß Delphi da was passendes im "Gepäck" hat.

Hat da noch jemand eine Idee ?

lg
Sebastian

[shmia]

Zitat:

Zitat von slemke76 (Beitrag 1046611)

ich brauche ein Objekt, das nur die Ergebnismenge aufnimmt, aber keinerlei Verbindungsdaten o.ä. und hatte gehofft, daß Delphi da was passendes im "Gepäck" hat.

Das wäre dann ein sogenanntes Memory-Dataset.
z.B. KBMemTable: http://cc.embarcadero.com/item/22476 und http://www.torry.net/pages.php?id=572
Auch in der RXLib und in der JVCL sind Memory-Datasets enthalten.
Und das ClientDataset aus den Delphi Enterprise Versionen kann auch als Memory-Dataset dienen.

[slemke76]

Hallo,

KBMemTable ist genau das, was ich gesucht habe - Hammer :-)
Danke für den Tip !!!

lg
Sebastian

[mkinzler]

In der JVCL gibt es soar ein spezialles CSV-DataSet

[slemke76]

Guten Morgen,

nu is schon fertig :-)

Trotzdem vielen Dank!

lg
Sebastian