Ich weiß, das Nachbohren nervt: Werden wirklich 250.000 Datensätze im Report dargestellt und muss das so sein? "Äh, die wollen das so" ist zunächst keine Antwort. Man kann ja auch mal anmerken, das es Probleme bereitet.
Wenn JA (weil z.B. Niemand nachdenken will, warum, und Du den Rotz ausbaden musst), dann geht es ja eigentlich nur um den Auftrag, diesen Mumpitz zu produzieren. Hier sollte man sich überlegen, ob man nicht anderweitig, also ohne diesen Reportbuilder, zum Ziel kommt. Das geht z.B. über Exportfunktionen des RDBMS: Die Daten werden also vom
DB-Server direkt in eine Datei geschrieben (z.B. EXCEL). Dann muss sich der Endanwender eben rumschlagen, wie er die 250k-Zeilen-Datei in seinen Rechner bekommt.
Andererseits kenne ich keinen Reportbuilder (und auch keinen Anwendungsfall), bei dem man durch diese Datenmassen scrollen muss. Die Vorgabe, beliebig viele Daten anzeigen zu können, ergibt sich meistens aus der Tatsache, das die Anwendung bestimmte Funktionen nicht bietet, die Anwender jedoch bestimmte Probleme lösen müssen.
Ich habe gerade konkret solche Fälle, bei denen es um die Massenkorrektur von Daten geht.
Die Daten müssen auf Eingabefehler oder Inkonsistenzen geprüft werden. Das kann die Anwendung nicht, also haben sich die Sachbearbeiter den Trick ausgedacht: Daten laden, als XLS-exportieren, in EXCEL öffnen und filtern/sortieren, um Probleme zu erkennen, dort korrigieren und als
CSV speichern. Dann wird aus der
CSV-Datei über RegEx eine Datei mit 100.000 UPDATE-Befehlen erstellt, die dann zum
DB-Server geschickt wird. Toll, gell?
Das Problem ist also hier z.B. das Fehlen einer direkten Exportfunktion, ohne Umweg über das Grid oder gleich das Richtige Datenvalidierungs- und korrekturtool.
Deshalb ist es so immens wichtig, den genauen Grund zu erfahren, wieso irgendwo 250k Datensätze aufgelistet werden müssen. Na, und wenn darauf bestanden wird, durch 250k Datensätze zu scrollen, dann baut man eben einen Pagingmechanismus, das sollte doch wohl gehen.