Hallo Laurent,

Du hast vollkommen recht, dass es hier um das Filtern von ZEILEN geht. Und ja, der Titel kann dadurch irreführend sein. Dennoch handelt es sich nicht um einen Irrtum. Viele Excelnutzer suchen nach „Spalten Filtern“, weil sie den Filter ja in einer Spalte setzt, auch wenn Sie diesen dann nutzen, um die Zeilen einzuschränken.

Danke für Deinen Kommentar und viele Grüße,
Lars

Die M Formel bestätigt aus meiner Sicht auch diese Annahme: Table.SelectRows

das hat mich in die richtige Richtung gebracht – vielen Dank.

Aber ich habe eine Frage: Warum hast du ContainsAny statt Contains verwendet? Ist das gleichwertig? Dann könntest du dir die geschweiften Klammern um das Feld [Buchstabe] sparen. Vor allem hat es bei mir aber auch einen riesigen Unterschied in der Performance gemacht: Bei ContainsAny wurden erst alle Daten vom SQL Server geladen (~100 Mio Zeilen – dauert ewig) und anschließend gefiltert. Wenn ich Contains verwende werden die Daten scheinbar direkt im SQL Server gefiltert und nur die relevanten geladen (~3 Mio Zeilen). Zumindest vermute ich aufgrund des Zeilen-Zählers und der Performance beim Aktualisieren, dass dies passiert.

Hast du damit Erfahrung oder weißt, warum sich PowerQuery da unterschiedlich verhält?

Viele Grüße!
Dominik

Nun habe ich aber das Problem, dass sich die Filterliste nicht aktualisiert, wenn ich eine Änderung vornehme. Könnte es daran lieben, dass die „Quellliste“ nur in Excel und nicht zusätzlich in PQ liegt? Dachte ich nehme als Quelle für die Liste die Tabelle aus der Exceldatei.
Du schreibst ganz oben: „Ausgangssituation ist, dass ich sowohl die zu filternden Werte, als auch die Filtertabelle in Power Query importiert habe.“ Das verwirrt mich etwas.

Hallo Lars,

habe die Lösung zwischenzeitlich selbst gefunden und will sie dir nicht vorenthalten:

Table.SelectRows(#“Vorheriger Schritt“, each List.ContainsAny({[Spalte_mit_Werten]},FilterListe,(x as text, y as text)=>Text.Contains(x,y)))

Die „Filterliste“ kann sowohl die ganze Zeichenfolge oder nur Anteile der zu suchenden Zeichen enthalten.

danke für den hilfreichen Artikel. Ich konnte deine Lösung bereits mehrfach erfolgreich einsetzen. Bei meinem aktuellen Datensatz würde ich diese Vorgehensweise auch gern anwenden, allerdings müsste dazu der dynamische Filter auch Textteile verwerten, anstatt nur eindeutige Treffer (Bsp.: die Spalte enthält Werte wie 01-2020/001, 02-2020/001, 02-2020/002, 03-2020/001 usw. Einige Werte kann ich eindeutig und vollständig aufzählen, bei anderen würde es helfen, wenn alle Werte ausgeschlossen werden, die mit 01/2020 beginnen, egal was danach folgt). Hast du dafür auch eine kompakte Lösung? Aktuell zerlege ich die Zeichenfolgen und filtere in mehreren Stufen, was allerdings immer wieder Eingriffe in die Abfrage erforderlich macht.

Viele Grüße, Sebastian

herzlichen Dank fürs Teilen deines Wissens und deiner Erfahrungen. Ich hatte heute die Anforderung einen dynamischen Filter für eine Spalte zu definieren. Mit meinen deutschsprachigen Suchbegriffen bin ich wieder einmal bei dir gelandet und fündig geworden.

In einem etwas anderen Sinne von ‚Sharing is caring‘ möchte ich hier kurz meine Erfahrungen mit dem listenbasierten Lösungsansatz zurückmelden und darlegen weshalb ich schlussendlich den Weg über einen Join gewählt habe:

Meine Selektionskriterien liegen in einer Excel-Zelle und waren durch Kommata getrennt. Beim Einlesen eines einzelnen Wertes stehen in Excel-PQ zunächst nur einige Transformations-Optionen an der Programmoberfläche zur Verfügung. Die Option ‚Text unterteilen“ (M-Funktion Text.Split() ) machte aus den Werten der Zelle die gewünschten Einzelwerte. Prima dachte ich, doch der Datentyp in der zu filternden Spalte war vom Typ Zahl. So lieferte die obige Lösung zunächst keine Datensätze, weil eine 1 vom Typ Text nicht einer 1 vom Typ Zahl entspricht. Also Liste in Tabelle umgewandelt, Typ auf Zahl geändert und wieder in eine Liste transformiert. So funktionierte es dann.

Bei den von mir verarbeiteten Quelldaten handelte es sich um SAP-Exporte im Textformat. Bei einer kleinen Datei mit knapp 4.000 Zeilen bemerkte ich schon, dass die Abfrage nach Implementierung des dynamischen List-Filters deutlich länger dauerte.

Die Performance beim Import einer Faktentabelle mit gut 250.000 Zeilen war dann nicht mehr akzeptabel. War die Abfrage vor Einbeziehung des dynamischen Listen-Filters nach 1:20 Minuten abgearbeitet, habe ich nach Einbeziehung des Listenfilters die Abfrage nach 15 Minuten abgebrochen. Da ich in der Erstellung der Abfrage keine Fehlermeldung erhalten habe und diese im Vorschau-Modus durchlief, gehe ich davon aus, dass ich die Umsetzung richtig gemacht habe. Anschließend habe ich den Weg über den InnerJoin ausprobiert, das Ergebnis lag hier nach 1:33 Minuten vor. Das war für mich vertretbar, so dass ich es bei der Join-Lösungsvariante belassen habe.

Vielleicht ist Performance ein Grund, weshalb gern die Join-Variante eingesetzt wird. Wie auch immer, der Impuls für die Lösung meines Problems kam aus deinem Post. Dafür nochmals besten Dank.

Sonnige Grüße aus Zeven
Jörg

Hallo Robert,

die einfachste Möglichkeit, dies in diesem Beispiel herzustellen ist, in Abfrage ‚dynamisches_Filtern_List_ContainsAny‘ den Schritt ‚Dynamischer_Filter_korrekt‘ mit einem >not< zu versehen: = Table.SelectRows(#"Geänderter Typ", each not List.ContainsAny(GesetzteFilter_Liste, {[Buchstabe]})). Vermutlich gibt es performantere Lösungen, aber mit dieser kleinen Umstellung kommst Du zumindest inhaltlich ans Ziel.

Viele Grüße,
Lars

ich fand den Text sehr verständlich. Die Ausführung mit Text und Screenshots finde ich sowieso besser als ein Video.
Allerdings sollte man sich vorher schon mit der grundlegenden syntax von M beschäftigt haben.

Gibt es auch eine Negierung hierzu?
Zeige nur Daten deren Schlüssel nicht in der Filtertabelle vorkommt.

Gruß Robert

Hallo Peter,

vielen Dank fürs Lesen meines Blogs. Ich nehme mir stets viel Zeit, um meine Artikel so verständlich wie möglich zu schreiben und erhalte dafür viel gutes Feedback von Lesern. Schade, dass es in Ihrem Fall nicht so aussieht. Ein gutes und verständliches Video zu drehen dauert gerne mal 1,5 Tage Arbeitszeit, die ich weder aufbringen kann noch möchte. Daher muss ich hier leider enttäuschen.

Viele Grüße,
Lars