Async Binding DataGrid

Hallo,

nachdem mir schon sehr mit der Async Problematik geholfen wurde und wie man das optimieren kann habe ich nun eine weitere Frage.

Ich verwende EF4.3 und lese folgendes aus:

IQueryable<duvReklLs> temp = from row in _db.duvReklLs where row.ls_Liefsch_Nr.Contains(para) select row;

Ich habe den Datentyp mal davor geschrieben aber eigentlich wird es einer Eigenschaft in meinem ViewModel zugewiesen.

Nun zu meinem Problem. Der Itemssource eines DataGrid ist an diese Eigenschaft gebunden. Nun habe ich festgestellt, dass das Laden bzw. Binding enorm lange dauert. IsAsync hilft da leider auch nicht. Nun würde ich ganz gerne wissen, wie man das "beschleunigen" kann. Sprich, ich möchte nicht, dass meine UI einfriert. Deshalb dachte ich mir, dass ich ja manuell die Items in temp laden könnte, und zwar asynchron und nicht erst wenn mein DataGrid über das Binding die Items nachlädt.

Hat jemand eine Idee wie ich das machen könnte?

Marc-O

Hallo

Du könntest hinter dem das ganze per ".ToList()" direkt laden lassen und diese Liste dann dem Datagrid zum Binden vorlegen oder eben einzeln per Foreach durchlaufen und die Elemente per Hand in eine Liste stecken. Wenn du das ganze dann noch in einen extra Thread auslagerst, friert dir auch deine UI nicht ein.

Aber mal eine andere Frage, welches DataGrid benutzt du, und um wieviele Daten reden wir da? Bzw. hast du mal überlegt ob die Abfrage nicht auch anderes stricken kannst damit deine Daten schneller gelesen werden können? Liegt ein Index auf der Spalte die du abfragst?

MfG Marco

Hey,

besten Dank für deine Antwort. Ja eine foreach Schleife habe ich auch schon eingebaut. Somit hatte ich die Daten schon lokal auf der Maschine. Problem ist aber, dass das Binding so enorm lange braucht. Alles andere ist ja schon komplett asynchron:-( Bevor ich gerade Feierabend gemacht habe, habe ich mal eben ein Paging mit eingebaut. Klappt soweit ganz gut aber mir dauert das laden immer noch zu lange:-(

Ich benutze das ganz normale WPF DataGrid. Die Abfrage an sich ist auch schnell. Clustered Index ist auch angegeben bla bla bla..Also der SQL Server hat keine Probleme. Dafür habe ich nämlich schon mal den Profiler angeworfen. Das erste Problem ist, dass ich eine Suche auf eine Lieferscheinnummer habe. Nun wollen die aber nicht explizit nach der Nummer suchen sondern auch nach Teilstring. Ich persönlich halte das auch für absolut Schwachsinnig aber nun gut.. Wenn man Pech hat, dann kommen da auch mal ganz locker 35.000 Zeilen zurück.

Das mit dem Paging klappt schon mal schneller als vorher. Jetzt lade ich immer nur noch 20 Zeilen aber selbst das dauert noch ca. 3 Sekunden!!!:-(

Marc-O

Hallo

Die Suche mit dem Teilstring ist verständlich von der Kundenseite aus, dass die es möchten und auch häufig nicht verstehen, welche Problematik dahinter steckt bei großen Datenbank, aber naja Kunde ist ja bekanntlich König :-).

Aber 3 Sekunden für 20 Zeilen find ich schon sehr arg, arbeitest du mit Take() und Skip() am EF? Oder wie machst du das Paging? Ich arbeite bei solchen Elemente normalerweise immer mit nachfolgenden Code:

int pageCnt = 20;
IQueryable<duvReklLs> temp = _db.duvReklLs.Where(x => x.ls_Liefsch_Nr.Contains(para)).Skip((page-1)*pageCnt).Take(pageCnt);

Wobei dies gut bei den ersten Seiten läuft, umso weiter man nach hinten geht, wird es bei großen Datenmengen langsamer.

Wen du das Paging selber erst in der Foreach-Schleife machst, lädst du trotzdem erst alle Daten zu deinen Client um sie dann durchzuarbeiten, also so wirklich sparst du dabei nichts.

Es gibt noch eine andere Möglichkeit, die zB vom DevExpress Grid benutzt wird, diese sind aber sehr Mathematisch und habs auch noch nie implementiert.

MfG Marco

Hey,

sorry für die verspätete Antwort. Ja genau, ich mache das auch via Skip und Take. Klappt auch ganz gut und die Ladezeiten sind auch "halbwegs" zu akzeptieren. Hab das jetzt so gelöst, dass ich asynchron über ToList() die Elemente lade so das ich sie schon mal im RAM habe und dann weise ich die Elemente meinem DataGrid zu.

Danke aber noch mal;-)