Listeneintrags-Limits unter Firemonkey?

[news2swen]

Hallo

ich habe im Forum nichts dazu gefunden, daher mache ich diesen Thread auf:

Gibt es irgendeine Beschränkung bei der Darstellung von Datensätzen mit Firemonkey?

Mir ist folgendes aufgefallen:
Ich habe ein ADODataset, welches ca 10.000 Datensätze liefert. Dieses Dataset habe ich an ein StringGrid gebunden. Dargestellt werden nur die ersten 2.000 Datensätze, danach ist Schluss.
Das hat mich stutzig gemacht, daher habe ich als nächstes die Datenquelle an einen Listview gebunden, aber auch da das gleiche Ergebnis.

Wie ertüchtige ich die Komponenten, mir die komplette Datenmenge darzustellen?

[Der schöne Günther]

Kenne mich damit nicht aus, aber das hier hört sich eher danach an, als wäre es eine Einstellung am Binding als am Control selbst

[news2swen]

vielen Dank, super Hinweis. Ich habe jetzt die AutoBufferCount-Property des Bindings auf true gestellt, und schon werden alle Daten eingeladen.

Problem ist nur, dass das extrem lang dauert (1Spalte mit 1.000.000 DS) und ein Click auf einen Datensatz in meinem Control dazu führt, dass das Programm erstmal eine reichliche Minute mit sich selbst beschäftigt ist Das war mit der 2000er Grenze nicht der Fall. Ein Teufelskreis

[Harry Stahl]

Ich habe leider keine Ahnung von der "typischen" Delphi Datenbankentwicklung und daher auch nicht vom ADODataset und wie das genau mit dem LiveBindings zusammenarbeitet.

Nach Deiner Beschreibung hört sich das aber so an, als ob die Daten tatsächlich in das StringGrid geladen würden.

Egal, welche Datenbank man im Hintergrund verwendet, aber das sollte man grundsätzlich vermeiden, insbesondere bei dieser hohen Anzahl von Datensätzen.

Wenn ich also einige tausende Datensätze in einem FireMonkey-Grid anzeigen möchte, dann verwende ich das TGrid (und nicht das TStringGrid). Denn das Grid hat das so nützliche "OnGetValue" Event, in dem Du das benötigte Datenelement zur Anzeige zur Verfügung stellen kannst:

Delphi-Quellcode:

procedure TForm10.Grid1GetValue(Sender: TObject; const Col, Row: Integer;
  var Value: TValue);
begin
  // Hier mit entsprechenden Bezug auf COL und Row den passenden Inhalt in Value zurückliefern
end;

Nur wenn ein Datenbank-Element also auch tatsächlich angezeigt werden soll, wird eine Dateninformation aus der Datenbank benötigt, daher geht die Anzeige sehr schnell (da macht es dann keinen Unterschied, ob 2.000 oder 2.000.000 Datensätze in der DB sind).

[Mavarik]

Zitat von news2swen:

Problem ist nur, dass das extrem lang dauert (1Spalte mit 1.000.000 DS) und ein Click auf einen Datensatz in meinem Control dazu führt, dass das Programm erstmal eine reichliche Minute mit sich selbst beschäftigt ist Das war mit der 2000er Grenze nicht der Fall. Ein Teufelskreis

Warum um alles in der Welt willst Du auch 1.000.000 Datensätze in ein Grid laden? Kann doch eh keiner sehen?
Wo ist der Sinn?

Ich würde nur 100 laden... und wenn der Benutzer mehr sehen will lade ich die nach...

[Der schöne Günther]

Ich war aber letztes Jahr in einer ähnlichen Situation. Kunde brauchte nur ein billiges Tool was ein paar Dinge aus einer Datenbank anzeigt und Graphen dazu malt.

Erst mit FireMonkey versucht, extrem langsam da erst die gesamte Ergebnismenge vom Server geladen wurde. Mit der VCL waren die Controls anscheinend so intelligent erst nachzuladen wenn man das DBGrid weiter runtergescrollt hat.

Ich kenne mich mit Datenbanken nicht aus und verstehe nicht, was sich mit dem "Cursor" und allem dahinter im Detail abspielt. Aber mit der VCL musste ich mich um so etwas nicht kümmern. So war ich dann auch schnell fertig.

[stahli]

Zitat von Mavarik:

Ich würde nur 100 laden... und wenn der Benutzer mehr sehen will lade ich die nach...

Das ist natürlich ein sinnvoller Ansatz.
Aber dieses Nachladen sollte m.E. automatisiert im Hintergrund erfolgen, ohne dass der Programmierer (oder alle Programmierer) das individuell selbst regeln müssen.

Man sollte m.E. immer die Möglichkeit haben, beliebige Datenmengen anzuzeigen.

Auch wenn niemand durch 1Mio Records scrollt, könnte man ja eine komplette Tabelle "anzeigen" und dem User dann Möglichkeiten zum Suchen und Filtern anbieten.

Vom Konzept her finde ich das auf jeden Fall anstrebenswert.

[Mavarik]

Zitat von stahli:

Aber dieses Nachladen sollte m.E. automatisiert im Hintergrund erfolgen, ohne dass der Programmierer (oder alle Programmierer) das individuell selbst regeln müssen.

Ja das macht doch Firedac auch so... oder?

Zitat von stahli:

Auch wenn niemand durch 1Mio Records scrollt, könnte man ja eine komplette Tabelle "anzeigen" und dem User dann Möglichkeiten zum Suchen und Filtern anbieten.

Vom Konzept her finde ich das auf jeden Fall anstrebenswert.

Ja aber doch bitte nicht das Grid als Container missbrauchen...

Grundregel Nr.1: Visuelle Componenten stellen Daten da, aber sind nicht die Struktur um die Daten zu halten...

Das gilt nicht nur für ein TEdit sondern für ALLE.

Du willst Suchen und Filtern? Logo... Kein Thema..

Thread starten mit der Suche oder dem Filter "LIMIT 100"...
Ergebnis da? Ab ins Grid...

Im Hintergrund gerne nochmal 100 suchen... Falls der User doch weiter scrollt... Mach er? Bup... Nächsten hundert ins Grid (die 1. Hundert ggf. vergessen) und wieder im Thread hundert laden...

So wird da ein Schuh draus...

[stahli]

Ob FireDAC das macht weiß ich nicht. Bei Benutzung der LiveBindings scheint das ja auf jeden Fall nicht bis zum Grid durchzuschlagen.
Aber da habe ich selbst keine Erfahrungen.


Dass Controls nicht als Datenspeicher fungieren sollen ist - denke ich mal - Konsens.


Mit Limit 100 und einer eigenen Buffer-Funktionalität würde ich eben gerade nicht arbeiten wollen. So wird für mich kein Schuh draus.
Ok, für den Enduser ist das dann in Ordnung. Er würde denken, dass er eine riesige Tabelle sieht, in der er sich bewegen und darin suchen und filtern kann.

Aber wenn man diese Lösung in seinen Projekten jeweils selbst realisieren muss, fände ich das eben unschön.

[Mavarik]

Zitat von stahli:

Aber wenn man diese Lösung in seinen Projekten jeweils selbst realisieren muss, fände ich das eben unschön.

Das klingt so als wäre das der riesen Aufwand...

Ich will mich doch nicht darauf verlassen, dass Datenbank XY, bzw. Datenbank Komponente XY das kann... Ich möchte doch unabhängig bleiben...

Also Wrapper ich doch sowieso erstmal die Komponente.

Dann bauche ich mir eine View... Davon leite ich eine PageableView ab...
Dann einen "Async-Kachel-Loader"...

Zum Schluss gebe ich dem ganzen im Constructor noch mein Wrapper Interface und schon bin ich unabhängig von der verwendetet Komponente und Datenbank.
Das Ganze mache ich 1x und nutze es als IPageableDataview in allen Projekten...