Datensätze paketweise in DBgrid laden

[S Hoffmann]

Hallo, ich verwende ADO und MSSQL-Server 7. Ich habe eine Tabelle mit sehr vielen Datensätzen (>200000). Wenn ich die alle auf einmal íns Grid lade, dann dauert das zu lange. Am liebsten würde ich zuerst nur die ersten 500 Datensätze ins Grid laden, und wenn der User ans Ende gescrollt hat, die Datensätze 500 bis 1000 HINZULADEN. Geht das? Muss man vieleicht ein eigenes Recordsetobjekt erzeugen/vererben?
Danke

[Dr.med.Bernhard Schwabe]

hallo S

grundsätzlich werden daten doch erst zur information, wenn sie für den user von interesse sind. bei > 2 * 10^6 daten stellt sich für mich als erstes die frage, wie kann ich die datenmenge vorher auf die für den user relevanten daten einschränken. aber gut, das ist ein problem deiner "programm-philosophie".

ich würde das problem mit einer query lösen. dabei könnte man über den dir bekannten eineindeutigen schlüssel gehen. es käme ja nicht darauf an, dass immer GENAU 500 oder 1000 sätze sichtbar sind. du triggerst die folgequery immer dann, wenn eof = true.

im übrigen ist die anzeigezeit deutlich reduziert, wenn du beim laden disablecontrols verwendest.

<PRE>
with query1 do begin
disableControls;
close;
sql.clear;
sql.add(sSQL); // sSQL sei eine StringVariable, in der du deine Abfrage gebastelt hast
open;
EnableControls;
end;

</PRE>
gruß
bernhard :

[S Hoffmann]

Leider hat mein Programm mit variablen Datenmengen zu tun: von 500 Datensätzen bis 5 Millionen: Ich filtere schon(nach Anfangsbuchstaben und anderen Kriterien); aber irgendwann versagt jeder Filter.
Bei deinem Vorschlag werden alle alten Ergebnisse gelöscht, ich müsste immer wieder dieselben Daten übers Netz ins Programm laden, was ich vermeiden wollte (Apropos: Der SQL-Server Enterprise-Manager arbeitet nach meinem Prinzip -- vielleicht geht das nur mit C++?

[Dr.med.Bernhard Schwabe]

haben alle felder den gleichen informationsgehalt? sonst könntest du das dbgrid emulieren und die daten in ein stringgrid einlesen. das ginge dann blockweise. für das editieren der daten müßtest du dann allerdings den speziellen datensatz nachladen

[S Hoffmann]

Genau das wollte ich eigentlich vermeiden, weil immer eine nicht-universelle Lösung. Mich ärgert es immer, wenn Microsoft besser ist als Delphi. Na Ja

[Dr.med.Bernhard Schwabe]

vielleicht können die das ? => http://www.objectsight.com/TopGridOverview.ht

[Andreas Kosch]

Hallo,

beim Zugriff auf eine SQL-Datenbank sollte man zum clientseitigen Cursor (clUseClient) greifen - aber dann lädt ADO beim Öffnen der Datenmenge sofort alle Datensätze in den eigenen Puffer. Wenn man wirklich 200 000 Datensätze im TDBGrid benötigt (was ich mir nicht vorstellen kann), hilft das <b>asynchrone</b> Laden weiter: Das Programm zeigt sofort die sichtbaren Datensätze im TDBGrid an, während ADO im Hintergrund die Daten nachlädt:
<pre>
ADODataSet1.ExecuteOptions := [eoAsyncFetchNonBlocking]
ADODataSet1.Active := True;
</pre>
Man kann dann sogar den Ladevorgang abbrechen:
<pre>
procedure TForm1.ADODataSet1FetchProgress(DataSet: TCustomADODataSet;
Progress, MaxProgress: Integer; var EventStatus: TEventStatus);
begin
StatusBar1.SimpleText := Format('%d Datensätze geladen',
[DataSet.RecordCount]);
if FCancelAsyncLoad then
DataSet.RecordSet.Cancel;
Application.ProcessMessages;
end;
</pre&gt

[S Hoffmann]

<B>Danke!</B>
Es scheint zu funktionieren, mit meinen wenigen Beispieldaten jedenfalls
Sicherlich ist es nicht sinnvoll 200.000 DS anzuzeigen, aber meine Devise heisst: Der Kunde ist König. Die meisten Anwender wollen, das alles wie Excel aussieht. Nun drum

[Bernd Milich]

Gibt es einen Grund, warum bei eoAsyncFetchNonBlocking die Filterfunktion (ADODataSet) nicht mehr funktioniert ?
Hintergrund : Auf einem Client werden sehr viele Suchoperationen durchgeführt und ausgewertet (quasi "Batchjob")