Als alter VBA-Entwickler bin ich immer noch begeistert von dem, was Microsoft Access so alles bietet. Anders als in VB 6, dem alten DataGrid in .NET 1.1 und der aktuellen DataGridView in .NET 2.0/3.0 kann die Listbox in Microsoft Access riesige Datenmengen anzeigen ohne auch nur mit der sprichwörtlichen Wimper zu zucken.
Beim Ladevorgang werden die Daten dabei Stück für Stück eingelesen, so dass sich die ersten Zeilen der Listbox augenscheinlich sofort füllen. Der Anwender hat den Eindruck, die Daten wären nach nur wenigen Millisekunden bereits verfügbar. Und tatsächlich kann der Anwender bereits mit den Daten arbeiten. Er kann beispielsweise eine Zeile markieren oder einen Bildlauf auf die Liste ausführen, obwohl im Hintergrund noch Daten nachgeladen werden.
Die DataGridView arbeitet leider nicht so. Das hat damit zu tun, dass das ganze .NET Framework auf die Arbeit mit Offline-Daten ausgelegt ist. Die DataGridView selbst kann Daten sehr performant anzeigen. Das rührt daher, dass sie als Datenquelle Daten aus bereits vorhandenen (!) Objekten erwartet, die eine der Schnittstellen IList, IListSource, IBindingList oder IBindingListView implementiert haben. Sobald man ein entsprechendes Objekt als Datenquelle ankoppelt, braucht die DataGridView die im Objekt gespeicherten Daten nur noch auf den Bildschirm zu zeichnen.
Das Problem ist also immer das Laden der Daten vom Speichermedium in den Arbeitsspeicher (also in das entsprechende Objekt, wie z.B. eine DataTable oder ein Array). Der gesamte Vorgang besteht also aus zwei Schritten: Erst die Daten in das Objekt laden, dann das Objekt an die DataGridView binden. Der Anwender hat dabei den Eindruck als stünde jemand auf der Leitung.
Daher habe ich mich entschieden, den Anwender mit einem Trick zu vertrösten. Ich teile die Arbeit auf und lade zunächst nur 100 Datensätze in das Objekt, die dem Anwender anschliessend in der DataGridView präsentiert werden. Während dieser dann schon mal beginnt, sich mit den Daten zu beschäftigen, lade ich einfach die komplette Datenmenge und stelle die DataGridView.DataSource dann noch einmal neu ein.
Natürlich ist das keinesfalls die eierlegende Wollmilchsau. Die Praxis zeigt aber, dass die Anwender gut mit diesem Trick leben können. Letzendlich dauert es meist nur einige Sekunden, bis die volle Datenmenge geladen ist. Solange ist man allemale mit dem ersten Eindruck auf dem Bildschirm beschäftigt.
Wer sich näher mit der Performance-Problematik bei DataGridViews beschäftigen möchte sei noch auf zwei interessante Seiten im www hingewiesen:
René Brunner zeigt, wie man beliebig große Daten performant verarbeiten kann (Ich selbst konnte mich mit dieser Lösung nicht anfreunden, weil man unendlich viel codieren muss)
http://megos.wordpress.com/2008/07/19/die-millionen-datagridview
Frank Dzaebel zeigt, wie performant die DataGridView selbst bei großen Mengen wie 200.000 Zeilen noch ist. Zu berücksichtigen ist dabei allerdings, dass er die Daten nicht von der Festplatte in ein Objekt lädt, sondern OnTheFly im Arbeitsspeicher in einem Array erzeugt. Daher war auch dieser Ansatz für mich nicht relevant. Trotzdem eine sehr schöne Recherche, wie ich finde.