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.