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

[alzaimar]

Da stimmt doch etwas an deinem Konzept nicht: Erst liest Du Daten in einen Container (hier: TADOQuery), schaufelst sie dann in einen zweiten Container und schiebst sie dann in eine CSV-Datei.

Die Zuständigkeiten sind nicht klar verteilt, Du hantierst mit Objekten, die versteckt erzeugt, aber vom Aufrufer freigegeben werden müssen. Das passt doch nicht.

Mein Vorschlag: Kapsele deine gesendeten Dinger (SentItems) in einer Klasse und stelle die Daten in einer Property vom Typ TDataset der Öffentlichkeit zur Verfügung.

Die Klasse verwaltet das Dataset auch, d.h. instantiiert es im Konstruktor und gibt es im Destruktor wieder frei.

Für ein TDataset gibt es reichlich Zusatztools, u.a. bestimmt auch einen CSV-Exporter, außerdem kannst Du sie ohne Probleme vor dem Export darstellen.

Eine Methode "ReadData" liest die Daten dann ein. Wenn Du sie abstrakt virtuell deklarierst, könntest Du sogar verschiedene spezialisierte Nachfahren der TSentItem-Klasse erstellen:
Eine liest per ADO aus einer DB, eine Andere aus einer XML-Datei. Je nachdem (wenn Du es brauchst).

Übrigens kannst Du die Daten per TADODataset einlesen und die temporäre Tabelle trotzdem löschen: Das TADODataset enthält ja schon eine In-Memory Kopie der Daten.

Delphi-Quellcode:

Type
  TSentItems = Class
  Public 
    Procedure ReadData();
    Property Data : TDataSet Read fData;
  End;

....

Var
  sentItems : TSentItems;

Begin
  sentItems := TSentItems.Create();
  Try
    sentItems.ReadData();
    ExportAsCSV (sentItems.Data);
  Finally
    sentItems.Free;
  End
End;