Tabelle aus PG Datenbank in StringGrid füllen?

[W4lt3r]

Hallo an alle,

ich habe gerade eine große Wissenslücke. Wie es schon im Titel steht muss ich einen StringGrid befühlen mit Inhalten aus einer Datenbank. Ich hab mich jetzt zu StringGrid belesen. Aber nichts gefunden was mir wirklich helfen würde. Meine erster Ansatz wäre eine Schleife die die Inhalte befüllt und das StringGrid automatisch erweitert. Allerdings bin ich mir nicht mal im klaren, ob das über Haupt ein guter Ansatz, geschweige den der richtige ist.

Wenn ihr eine Idee zu dem Thema hättet oder wenigstens ein Hinweis in welche Richtung ich suchen muss, würde das mir schon sehr viel bringen.

Schon mal Danke für alle Beiträge.

W4lt3r

[DeddyH]

Muss es denn unbedingt ein StringGrid sein? Wenn man keine datensensitiven Controls (z.B. DBGrid) verwenden darf/soll/möchte, würde ich eher in Richtung ListView mit ViewStyle vsReport tendieren. Mit der Schleife hast Du schon recht, und für das dynamische Einfügen von Zeilen finde ich ganz persönlich die ListView etwas eleganter.

[W4lt3r]

Ich will kein DBGrid verwenden weil es um Tabellen geht die über 5 mio. Datensätze enthalten und dabei reicht der Arbeitsspeicher nicht. Und nun ja mir wurde gesagt das ich StringGrid benutzen soll.

[DeddyH]

Das hat aber doch weniger mit der Darstellungskomponente zu tun als damit, wie man das zugrundeliegende Dataset konfiguriert. Welcher Mensch will denn auf einen Schlag 5.000.000 Datensätze angezeigt bekommen?

[Delphi.Narium]

Die Menge der Daten ist bei 'nem StringGrid sicherlich ausschlaggebend für den Speicherverbrauch.

Bei 'nem DBGrid wird nur das geladen, was auch angezeigt wird, es sei denn, dass man die Datenbankkomponenten (DataSet und Nachfolger) drum "bittet", alle Datensätze in den Arbeitstspeicher zu laden. Oder z. B. den Datencursor auf den Client legt, der muss dann zwangsweise alle Daten vorhalten, auch ohne Anzeige.

Aber wenn's denn ein StringGrid sein muss:

Delphi-Quellcode:

StringGrid.Cols := DataSet.Fields.Count;
StringGrid.Rows := DataSet.RecordCount;
DataSet.First;
while not DataSet.EoF do begin
  for i := 0 to StringGrid.Cols - 1 do StringGrid.Cells[i, DataSet.RecNo] := DataSet.Fields[i].AsString;
  DataSet.Next;
end;

Die Sinnhaftigkeit dieses Vorgehens bei genannter Datenmenge, zweifle ich allerdings an.

Ein DBGrid zeigt übrigens "nur" die bereits im DataSet befindlichen Daten an, bei einem StringGrid muss man von den Daten noch 'ne Kopie anlegen (Cells[x,y] := Feldinhalt).
Was mag letztlich dann mehr Speicher verbrauchen? Nur die Daten, die sowieso schon den Speicher sprengen oder diese Daten plus die Kopie im Stringgrid?

Und beim Stringgrid muss man die Formatierungen (rechts- / linksbündig, je nachdem ob Text oder Zahlen, Nachkommastellen ...) gefälligst selber machen.

Um sowas zu machen, müsste ich schon sehr verzweifelt sein.
Oder eine objektorientierte Applikation schreiben, bei der Anzeige und Datenhaltung streng getrennt sind. Aber das dann sicherlich nicht mit der gleichzeitigen Anzeige von 5.000.000 und mehr Objekten.

[jobo]

Ich schätze/hoffe mal, dass die 5 mio hier nur ein Missverständnis in der Nutzung der Komponenten ist. Also auch die Stringgridvariante nur ein "Workaroung" ist, um einen Teil der Daten anzuzeigen.
Geht es dann letztlich um die Anzeige eines Teils der Datenmenge, so können sehr wohl datensensitive Komponenten genutzt werden. Die bekommen dann eben nur eine definierte Menge an Daten geliefert.
Das wäre vielleicht das Gewollte, wenn man davon ausgeht, dass die standard Verwendungsmöglichkeiten dieser Komponenten (noch) nicht bekannt sind.

[himitsu]

Zitat:

Muss es denn unbedingt ein StringGrid sein? Wenn man keine datensensitiven Controls (z.B. DBGrid) verwenden darf/soll/möchte

Aber wenn es nicht "verboten" ist, dann wäre natülich eine Datensensitive Komponente bestimmt besser einfacher.

[edit]
Beim TStringGrid muß auch alles in den Speicher.
Zwar nicht "dauernd" doppelt (außer eventuell beim Befüllen), also Daten im DataSet und als Kopie im DataController des Grids

Wenn der Speicher das Problem ist, dann würde ich eher in Richtung VirtuelStringTree (nur 1. Ebene, also als Grid) tendieren.



Oder einen passenden Filter+Limit auf die Daten und weniger anzeigen. (siehe nachfolgend DeddyH)

Oder die Anwendung als 64 Bit.