Daten schnell in VST laden

[youuu]

Hi,

wie lade ich am schnellsten mehrere 1.000 Daten in ein VST?
Momentan mach ich es über (gekürzt):

Delphi-Quellcode:

    liste.test1:= Query.FieldByName('test1').AsWideString;      
    Vst.addchild(nil, liste);

Jedoch dauert diese Art extrem lange.

[wicht]

Delphi-Quellcode:

Vst.RootNodeCount := 10000;

und dann im OnGetText-Event den passenden Text rausgeben. Das wäre eine Möglichkeit.

[Satty67]

Ja, denke wie bei jedem WinControl (z.B. auch StringGrid) bei größeren Datenmengen nichts in das Control laden sondern nur den sichbaren Abschnitt aus der externen Datenquelle laden und bereit stellen.

[Luckie]

Was soll der Benutzer mit tausend Datensätzen anfangen? Ich wäre da ziemlich überfordert, wenn ich die alle durchsehen müsste, um meine gewünschte Information zu bekommen.

[wicht]

Das ist natürlich wahr, aber eben eine der Stärken des VST :P

Die Frage ist auch noch, falls das hier youuu alles nicht so weiterhilft, wie er den Baum befüllt. Von welchem Typ ist das Objekt "liste"? Meine Zeit mit den DB-Komponenten ist lange vorbei... Macht er erst eine Query, iteriert dann über das Ergebnis und fügt jedes Node einzeln hinzu? Der Fehler wird vermutlich sein, dass das virtuelle Paradigma, oder wie man das nennt, hier nicht befolgt wurde. Selbst ein simples VST.Add() geht glaube ich noch recht schnell, auch wenn man es sehr sehr oft hintereinander aufruft. Das RootNodeCount ist aber der bessere Weg, denke ich.

Ich würde es mal so versuchen:
Query machen, Ergebnis irgendwo merken, RootNodeCount auf die Anzahl der Zeilen im Ergebnis setzen. Im OnGetText-Ereignis dann auf das gecachete Query-Ergebnis zugreifen und den passenden Text rausrücken. Dabei könnte man zum Beispiel den Index des Nodes, für welches OnGetText aufgerufen wird, benutzen, um die passenden Daten aus der Ergebnismenge herauszufischen.

Falls das auch noch nicht reicht.. etwas mehr Code, bitte :-D.. und Entschuldigung für meine sehr knappe Antwort von vorhin. Ich musste weg, aber musste trotzdem noch antworten, war so ein innerer Zwang.

Gute Nacht.

[youuu]

Morgen, bin gestern eingepennt :)

Also, ich mach ein Query auf die DB, fülle die Klasse Liste und pack es in das VST.

Delphi-Quellcode:

    Query.SQL.Text := 'Query String'

    Query.Open;

    while not Query.eof do
    Begin
      Liste := TListe.Create;
      with Liste do
      Begin
        liste.test1:= Query.FieldByName('test1').AsWideString;       
        .
        .
        .
      end;

      Vst.addchild(nil, Liste);

      Query.Next;
    End;

[wicht]

Hi,

mach doch mal zwei Schleifen, eine, die z.B. ein Array mit den "Liste"-Objekten befüllt, und dann eine, die die Nodes hinzufügt, basierend auf dem Array. Und dann guck mal, welche die meiste Zeit verbraucht. Ich vermute, dass die DB-Sachen dauern, das .Add() aber ganz schnell geht. Und falls nicht, versuch es mal mit dem RootNodeCount, wie oben vorgeschlagen.

HTH

[youuu]

Dann wird aber Zeit gleich bleiben im Endeffekt?
Oder verstehe ich das falsch?

[Stevie]

RootNodeCount auf RecordCount des DataSets setzen und im GetText den Datensatz im Dataset über den NodeIndex referenzieren. Dann wird beim Scrollen durch den VST auch im Dataset gescrollt.

Delphi-Quellcode:

  ds.Open;
  vst.RootNodeCount := ds.RecordCount;

...

// Im OnGetText
// Setzt vorraus, dass du vorher Columns im VST angelegt hast, 
// die vom Index genau zu seinen Feldern im Dataset passen
// ansonsten einfach nen bestimmtes Feld nehmen
  if Column > -1 then
  begin
    ds.RecNo := Node.Index + 1;
    CellText := ds.Fields[Column].AsString;
  end;

@Luckie: Solch eine pauschale Aussage halte ich für überflüssig, es gibt durchaus Anwendungsfälle, wo man viele Daten präsentiert bekommt. Ob man dann eine weitere Auswertung durchführen kann (über Filter etc) steht auf einem anderen Blatt. 2 Fälle die mir sofort einfallen: 1. Anschauen eines Logs, 2. SQL Tool

[Luckie]

Zitat:

Zitat von Stevie (Beitrag 1049773)

Ob man dann eine weitere Auswertung durchführen kann (über Filter etc) steht auf einem anderen Blatt. 2 Fälle die mir sofort einfallen: 1. Anschauen eines Logs, 2. SQL Tool

Und warum dann den Filter nicht schon vorher anwenden?

[Stevie]

Zitat:

Zitat von Luckie (Beitrag 1049774)

Zitat:

Zitat von Stevie (Beitrag 1049773)

Ob man dann eine weitere Auswertung durchführen kann (über Filter etc) steht auf einem anderen Blatt. 2 Fälle die mir sofort einfallen: 1. Anschauen eines Logs, 2. SQL Tool

Und warum dann den Filter nicht schon vorher anwenden?

Wenn ich mir ein Log anschaue, was nunmal drölftausend Einträge hat, dann bekomm ich sie präsentiert.
Dann kann Clientseitig nen Filter anwenden um auszuwerten. Was würde nach deinem Prinzip wohl passieren, wenn ich den Filte ändere? Neue Anfrage an die Datenbank/Datenquelle.
Wenn ich nen select * from tabelle_mit_fünf_millionen_datensätzen mache, dann kommen 5 Millionen Datensätze (mal davon abgesehen, ob das clever ist oder nicht)

Wird aber nun off topic - Lösungsvorschläge zum Ursprungsproblem wurden gegeben.

[youuu]

Ein Filter ist vorhanden, allerdings möchte ich vorher alle Daten holen und dann kommt der Filter der den Rest unsichtbar macht und jenachdem, ob man mehr sehen möchte wird der Filter dann abgeschwächt und holt nicht jedesmal die Daten neu rein, da das dann wieder Ewigkeiten dauert.

[youuu]

Hab es hin bekommen, Danke.

Hab nun allerdings eine weitere Frage bezüglich der Datenbankabfrage, ich denke es ist besser dies in einem neuen Thread zu tun.

[Stevie]

Geh ich richtig in der Annahme, dass du MyDAC benutzt? Dort hast du doch eine TMyQuery Komponente. Die ist (höchstwahrscheinlich?) von TDataSet abgeleitet und bietet somit alle Methoden/Eigenschaften, die du benötigst.

Edit: Falls du UniDAC benutzt, hast du die TUniQuery Komponente.