BindingSource.Filters als separate DataTable

Hallo an alle,
ich sitze mal wieder auf der Leitung.

In meiner Applikation habe ich ein BindingSource an eine DataTable gebunden und diese wiederum mit einem DataGridView verbunden.
Nun hat der Anwender die Möglichkeit über ein Maske sich einen Filter zusammen zu stellen, um eine Liste für seine Arbeitsgrundlage zusammen zu stellen.

Soweit so gut, aber wenn er nun an den Elementen arbeitet, verändern die sich natürlich und damit schlägt der Filter zu. Kurz er sieht die bearbeiteten Elemente nicht mehr. Will er aber, 😦

Gibt es eine Möglichkeit das Result des BindingSource.Filters als separate DataTable zu exportieren und das an das DataGridView zu hängen?
Ich habe irgendwie nichts gefunden, was z.B. wie im DataGridView.Selected mir eine Untermenge zurück gibt.

Danke und Gruß
Bonvie

Idee: mit den Filterkriterien ein entsprechend passendes SQL-Statement generieren und dieses gegen die DB abschicken -> damit eine neue Tabelle 'erzeugen' und diese mit einer BindingSource an das DGV anbinden.
Solange die Änderungen in dieser gefilterten Tabelle nicht in die DB geupdatet werden, hat der Anwender Zugriff auf seine geänderten Daten, ohne das ein Filter zuschlägt.
Erst nach dem Update in die DB und erneuten Reload der Daten (mit gleichem Filterkriterien) sind diese dann natürlich nicht mehr 'greifbar'.

Generell: ich mache es grundsätzlich in der oben beschriebenen Art; ich lasse den Anwender seine Filterkriterien selbst zusammenstellen anhand von COmboboxen etc und setze dann ein entsprechend flexibel erstelltes SQL-SELECT an die DB ab. GErade bei sehr grossen Datenmengen macht sich das bemerkbar. Tausende von Datensätzen auf eine Rutsch in eine DGV zu laden, damit de Anwender dann schön scrollen kann, muss nicht sein (jaja, es gibt Anwender, die wollen das so..).
MEine Erfahrungen: mit Filtern=Suchen ist der Anwender besser bedient und die Daten sind schneller greifbar.

Gruss Rainer

oder eine 2. DataTable erzeugen, und in einer Schleife mit dem Filter-Ergebnis befüllen.

Dann gehts ohne DB-Zugriff.

Bei beiden vorgehensweisen ist zu beachten, dass man die Daten doppelt, also redundant hat. Da mussman aufpassen, wo Bearbeitung zulassen, und was abspeichern.

BindingSource.Filter setzt auch nur den RowFilter des DefaultView der DataTable.
Also ist per http://msdn.microsoft.com/de-de/library/system.data.dataview.totable%28VS.80%29.aspx daraus auch einfach eine DT zu machen.

Hey, den kannte ich noch gar nicht! 🙂

Nur, wennman eine typisierte DataTable haben will, muss mans doch selber machen (naja, ca. 4 Zeilen)

Edit: Es ist nicht immer der DefaultView der DataTable. Bei untergeordneten Views kannes auch ein RelatedDataView sein.

Also immer das DataView der Bindingsource verwenden

(DataView)BindingSource.List

Hmm, inzwischen neige ich wieder zu raiguns Variante. Also der User stellt einen Filter ein, und beim Button "ApplyFilter" werden die bestehenden Daten nicht mit BindingSource.Filter gefiltert, sondern verworfen und ersetzt durch die eingeschränkte Datenmenge.
Dann hat man auch keine redundanten Daten, und kein Filter schlägt zu.

Erstmal danke für das viele Feedback, aber sorry ich habe es noch nicht verstanden.

Also wenn ich den Filter des BindingSource nicht benutzen soll, welchen denn dann.
Und wann wird dieser verworfen bzw. wann habe ich eine Untermenge die ich bearbeiten kann.

Also ich denke mir würde auch reichen, wenn ich einen art selected Status setzen könnte, den Filter aufhebe bzw auf selected filtere und den Benutzer munter seine Arbeit erledigen lasse. Wenn der Benutzer fertig ist, kann er den Filter löschen und sieht wieder "alle" Datensätze.

Na, du lässt den user die Kriterien eingeben, und bastelst daraus einen SQL-String. Den gibst du einem DBCommand, dieses einem DataAdapter, und der befüllt die DataTable neu.

Wenn du mit typisierten Datassets arbeitest, kannst du im Dataset-Designer eine Zusätzliche Query hinzufügen , welche in einer zusätzlichen Fill-Methode resultiert (nenne sie "FillbyCriteria()"). Damit kannste deine Suche (wie gesagt: jetzt ist es keine Filterung mehr, sondern eine Suche) schön typisiert abrufen.

edit: Das mit der Query kann etwa so aussehen:

Also ich denke mir würde auch reichen, wenn ich einen art selected Status setzen könnte, den Filter aufhebe bzw auf selected filtere und den Benutzer munter seine Arbeit erledigen lasse. Wenn der Benutzer fertig ist, kann er den Filter löschen und sieht wieder "alle" Datensätze.

Löst das denn dein eingangs-Problem?

Dass nämlich durch eine Bearbeitung die Datensätze evtl. nicht mehr den Kriterien entsprechen, und somit ausgefiltert werden?

IMO läßt sich Filtern und Bearbeiten nur kombinieren, wenn die Bearbeitung derjenigen Spalten, nach denen gefiltert wird, unterbunden ist.

Oh, danke jetzt hat’s klick gemacht.
Das heißt dort wo eigentlich immer alle Datensätze liegen, liegen jetzt nur die gefilterten allerdings ohne aktiven Filter.

OK, dann lass mich bitte mal weiterspinnen.
Könnte ich nun mit zwei Datasets arbeiten. Das eine lassen wie es ist und ein zweites lediglich mit diesem neuen FillBy betanken, an das DataGridView für den Benutzer binden und er hat seine gewünschte Ansicht.

Die Bearbeitung der Daten findet allerdings im ersten Dataset statt.
Wenn der Benutzer fertig ist, muss ich nur noch das DataGridview umhängen und das zweite Dataset löschen.
Dann muss ich allerdings die Änderungen, doppelt verarbeiten, sonst sieht der Anwender seine Änderungen gar nicht. 😦

Ist das für die gewünschte Ansicht zu aufwendig und zu Ressourcen hungrig?
Ich teste mal und berichte.

Ja würde es,
er filtert z.B. alle Leute mit A, diese erhalten bei der Auswahl den Staus selected. Jetzt verändere ich programmatisch den Filter auf nur selected und der Benutzer kann gerne den Datensatz beliebig verändern, da er ja weiterhin den Staus selected hat.

Mir kommt das komplizierter als nötig vor.

2 Datasets, eines gefiltert, bearbeitet wird aber nur im anderen, und dann wird erst gefiltert, und dann eine zusätzliche Selected-Property auf true gestellt, und dann der filter umgestellt...

Warum nicht die Filter-Idee in die Tonne treten, und der suche-Idee anhangen?

Da gibts nur ein Dataset, und da sind die Suchergebnisse drin. Und wenn der User noch kein Kriterium gesetzt hat, sind halt alle Datensätze drin.

Und können bearbeitet werden.

Ja und nein, es sind sicher zwei verschiedne Ansätze und sollen nicht kombiniert werden, d.h. entweder oder.

Aber jedenfalls danke für die Diskussion.
Ich werde mich noch mal hier intern beraten welchen weg wir einschlagen.

Hallo,

ich greif noch mal die Eingangssituation auf:

In meiner Applikation habe ich ein BindingSource an eine DataTable gebunden und diese wiederum mit einem DataGridView verbunden.
Nun hat der Anwender die Möglichkeit über ein Maske sich einen Filter zusammen zu stellen, um eine Liste für seine Arbeitsgrundlage zusammen zu stellen.

Das heisst für mich ganz klar folgender Weg:
Anhand der Filterkriteterien ein entsprechendes SQL-SELECT-Statement dynamisch erstellen und gegen die DB absetzen. Die Tabelle mit den gefilterten Datensätzen an die gleiche BindingSource anhängen wie die urprüngliche (alle Datensätze enthaltende Tabelle). Somit hat das angehängte DGV eben NUR diese Datensätze, die dann nach Belieben bearbeitet werden können und dann auch als Update in die DB geschrieben werden können.
Vorteil: a) nur eine 'gültige' DataTable, b) keine redundanten Daten (in verschiedenen DataTables), c) Bearbeitung der Daten erfolgt einheitlich (weil ja nur eine BindingSource vorhanden ist), d) keine Auswirkung auf die gefilterten Datensätze, wenn sich ein Filter-Feldwert ändert - solange die Änderungen noch nicht in die DB geupdatet wurden

Wenn der Anwender mit seinen Änderungen zufrieden ist und diese abspeichert, kann er entweder den Filter nochmals aufrufen oder aber er setzt den Filter ausser Kraft -> alle Datensätze anzeigen.

WIe bereits in meinem ersten Posting erwähnt, mache ich es grundsätzlich so; in der Regel sucht / filtert der Anwender seine Daten nach entsprechenden Kriterien und nur diese Datensätze werden ihm angezeigt und können bearbeitet werden.
Und dabei bedine ich mich nur EINER BindingSource, an der das DGV (oder eine andere äquivalente ANzeigekomponente) hängt.

Soweit mal meine Gedanken und Anregungen.

Gruss
Rainer