Hallo Daten-Freunde! Hand aufs Herz: Wer von euch hat nicht schon mal eine Power Query Abfra­ge gebaut, die per­fekt lief… bis zum nächs­ten Daten-Refresh? Plötz­lich schreit der Power BI Report vor Feh­lern, dein Chef braucht die Aus­wer­tung und du bist am Verzweifeln.🫨

Die Ursa­che? Oft sind es klei­ne, unschein­ba­re Ände­run­gen in den Quell­da­ten, die dei­ne Abfra­ge ins Strau­cheln brin­gen. Rich­tig gehört, du bist für das Dilem­ma oft­mals gar nicht ver­ant­wort­lich.😉

Das ist natür­lich ärger­lich. Wir inves­tie­ren viel Zeit in den Auf­bau unse­rer Daten­mo­del­le, nur um dann von Klei­nig­kei­ten aus­ge­bremst zu wer­den.😐 Aber ich habe gute Nach­rich­ten: Wir kön­nen uns vor den gän­gigs­ten Feh­ler­quel­len absi­chern, bevor sie uns über­haupt in die Que­re kommen.

Heu­te tau­chen wir ein in 5 genia­le Tricks, die dei­ne Power Query Abfra­gen sta­bi­ler, dyna­mi­scher und deut­lich weni­ger feh­ler­an­fäl­lig machen. Wenn du also genug hast von Refresh-Fehlern und frus­trie­ren­der Feh­ler­su­che, bleib dran! Ich mache dei­ne Daten­ab­fra­gen sicher vor Fehlern.🙂

Trick 1: Groß- und Kleinschreibung ignorieren

Stell dir vor, du kon­so­li­dierst Daten aus ver­schie­de­nen Quel­len und hast Benut­zer­ein­ga­ben, wo der Wert “Pro­dukt A” mal als “Pro­dukt A”, mal als “pro­dukt A” oder sogar als “PRODUKT A” erfasst wird. Für uns Men­schen ist das klar, aber Power Query ist da… nun ja, sehr exakt.

Wenn du dann Tabel­len basie­rend auf die­sen Wer­ten zusam­men­füh­ren möch­test (mit­tels Table.NestedJoin / Table.Join) oder nach ihnen grup­pierst, führt dies zu Pro­ble­men: “Pro­dukt A” und “pro­dukt A” wer­den als sepa­ra­te Enti­tä­ten behan­delt, obwohl sie inhalt­lich das­sel­be mei­nen. Je nach Funk­ti­on gibt es ande­ren Weg, um Ver­glei­che unab­hän­gig von ihrer Schreib­wei­se durchzuführen.

Hier eini­ge Anwendungsbeispiele

• Tabel­len zusam­men­füh­ren (Fuz­zy­über­ein­stim­mun­gen)
  Wenn du zwei Tabel­len anhand einer Schlüs­sel­spal­te zusam­men­führst und die Groß-/Kleinschreibung der Wer­te vari­ie­ren kann, jedoch inhalt­lich das­sel­be bedeu­ten.
  Anstatt:
  Table.NestedJoin(Tabelle1,{"Artikelbez"},Tabelle2,{"Artikelbez"},"NeueSpalte",JoinKind.Inner)

Nutzt du:
Table.NestedJoin(Tabelle1,{"Artikelbez"},Tabelle2,{"Artikelbez"},"NeueSpalte",JoinKind.Inner, [IgnoreCase=true,Threshold=1])

Schon wer­den “Arti­kelA”, “arti­kelA” und “Arti­kela” beim Join als iden­tisch behan­delt!

• Grup­pie­ren von Daten (Comparer.OrdinalIgnoreCase)
  Wenn du Daten nach einer Spal­te grup­pie­ren möch­test und dabei die Groß-/Kleinschreibung der Wer­te igno­rierst, um inkon­sis­ten­te Ein­trä­ge zu einer Grup­pe zusam­men­zu­fas­sen.

Hier wür­de “Apfel” und “apfel” als eine Grup­pe behan­delt wer­den, wenn du nach “Pro­dukt­na­me” gruppierst. 

• Fil­tern (Comparer.OrdinalIgnoreCase)
  Wenn du zei­len­wei­se nach Text­in­hal­ten fil­terst, wo die Groß- / Klein­schrei­bung nicht strikt ein­ge­hal­ten wird, z.B. bei der Suche nach “Bericht” vs. “bericht”. Das kann dir auch das Suchen nach bei­den Schreib­wei­sen erspa­ren und den Code ver­kür­zen.
  Anstatt:

Nutzt du:

Dadurch wer­den sowohl Zei­len mit Inhalt “Bericht” als auch “bericht” oder auch ande­re Vari­an­ten wie “BeRiCHt” ausgegeben.

Trick 2: Spalten dynamisch erweitern

Die­ser Feh­ler ist ein Klas­si­ker: Du hast eine Lis­te von Records / Tabel­len in einer Spal­te, die du erwei­tern möch­test. Das Pro­blem? Wenn sich die zugrun­de­lie­gen­den Spal­ten (Fel­der) in die­sen Records oder Tabel­len ändern – zum Bei­spiel, weil in einer Zei­le ein Feld fehlt oder ein neu­es Feld auf­taucht – bricht dei­ne Abfra­ge zusam­men. Power Query erwar­tet, dass benann­te Spal­ten exis­tie­ren.

Der Trick hier ist, die Namen der Spal­ten, die du erwei­tern möch­test, dyna­misch zu iden­ti­fi­zie­ren, anstatt sie hart zu kodie­ren.

Record.FieldNames

Record.FieldNames(Quelle[Spalte]{Zeilennummer})
Funk­tio­niert, wenn alle dei­ne Records die glei­chen Fel­der (Spal­ten­na­men) haben. Ich nut­ze die­sen Trick ger­ne, wenn ich meh­re­re Spal­ten in einem Step hinzufüge.

Table.ColumnNames

Table.ColumnNames(Table.Combine(Quelle[Spaltenname]))
Die­se Funktions-Kombi ist super, wenn du eine Lis­te von Tabel­len mit ver­schie­de­nen Spal­ten­na­men hast. Bei­spiel: Monat­li­che Budget-Dateien mit glei­chen Spal­ten am Anfang (z. B. Abtei­lungs­ID, Abtei­lungs­Na­me) aber unter­schied­li­chen Namen für die Werte-Spalte (Janu­ar, Februar, …).

Ange­nom­men, du hast eine Tabel­le Trans­ak­tio­nen mit einer Spal­te Details, die pro Zei­le eine Tabel­le ent­hält. Im Nor­mal­fall erhältst du per Benut­zer­ober­flä­che (Spal­te erwei­tern) die­sen Code:

Statt die Spal­ten als sta­ti­sche Lis­te anzu­ge­ben, kannst du mit der Kom­bi alle Spal­ten­na­men aller Tabel­len dyna­misch zie­hen.

Neue Spal­ten wer­den auto­ma­tisch erkannt und hin­zu­ge­fügt, feh­len­de Spal­ten ver­ur­sa­chen kei­nen Feh­ler.

Trick 3: Fehlende Spalten ignorieren

Oft arbei­test du mit Daten­quel­len, die nicht immer die glei­chen Spal­ten­na­men lie­fern. Du hast viel­leicht eine Spal­te Kun­denID, die aber manch­mal als Bestel­ler­ID auf­taucht, oder bei älte­ren Daten ganz fehlt. Wenn du ver­suchst, eine Spal­te umzu­be­nen­nen, die nicht exis­tiert, bricht dei­ne Abfra­ge ab.

Der Trick ist, bevor die Umbe­nen­nung statt­fin­det, zu prü­fen, ob die Spal­te über­haupt exis­tiert. Wenn ja, wird sie umbe­nannt. Wenn nicht, wird sie igno­riert.

Hier­für kommt der Para­me­ter MissingField.Ignore zum Ein­satz.
Wenn jetzt die Spal­te Kun­denID im Tabel­len­ob­jekt Quel­le nicht gefun­den wird, wirft Table.RenameColumns kei­nen Feh­ler. Statt­des­sen wird die Umbe­nen­nung für die­se spe­zi­fi­sche Spal­te ein­fach über­gan­gen. Die Abfra­ge läuft ohne Unter­bre­chung wei­ter. Geni­al!

Bei­spiel
Uns liegt eine Power Query Abfra­ge mit den Spal­ten Pro­dukt­na­me & Anzahl vor. Die Spal­te Pro­dukt­na­me soll in der Abfra­ge in Pro­dukt­bez umbe­nannt wer­den. Jedoch wur­de die­se Spal­te ent­fernt. Dadurch wird ein Feh­ler erzeugt, der Query funk­tio­niert nicht mehr.

Anstatt:
Table.RenameColumns(Tabelle1, {"KundenID", "Kundennummer"})
Nutzt du:
Table.RenameColumns(Tabelle1, {"KundenID", "Kundennummer"}, MissingField.Ignore)

Dadurch läuft dei­ne Abfra­ge sta­bil wei­ter, auch wenn die Spal­te gar nicht exis­tiert.

Trick 4: Fehler gezielt abfangen

Power Query ver­fügt über eine ver­läss­li­che Feh­ler­be­hand­lung mit try … other­wi­se. Die­se zwei Zau­ber­wör­ter sind das Pen­dant zur Excel-Funktion WENNFEHLER(). Die Kom­bi erlaubt dir, Code-Blöcke zu umwi­ckeln, die poten­zi­ell Feh­ler wer­fen könn­ten, und dar­auf zu reagie­ren. Anstatt dass dei­ne gesam­te Abfra­ge abstürzt, kannst du den Feh­ler abfan­gen und eine alter­na­ti­ve Akti­on aus­füh­ren.

Bei­spiel
Du hast eine Spal­te Preis­Text, die Zah­len als Text ent­hält, aber auch “N/A” oder ähn­li­ches. Du möch­test die Zah­len als Zahl typi­sie­ren.

Trick 5: Fehler auslesen & Details protokollieren

Manch­mal reicht es nicht, einen Feh­ler nur abzu­fan­gen und einen null Wert ein­zu­set­zen. Du möch­test wis­sen, was genau schief­ge­lau­fen ist.

Gute Nach­rich­ten! Jeder Feh­ler in Power Query hat eine detail­lier­te Feh­ler­mel­dung, die du extra­hie­ren kannst. Das ist Gold wert, um Daten­qua­li­täts­pro­ble­me zu iden­ti­fi­zie­ren oder die Ursa­che eines Feh­lers zu debug­gen.

Die­ser Trick baut direkt auf dem try…otherwise-Konzept auf. Anstatt einen fes­ten Wert zurück­zu­ge­ben, wenn ein Feh­ler auf­tritt, fängt try das Ergeb­nis als Record ab. Die­ser Record ent­hält ent­we­der den ursprüng­li­chen Wert (wenn erfolg­reich) oder einen Error-Record (wenn ein Feh­ler auf­trat). Du kannst dann prü­fen, ob es sich um einen Feh­ler han­delt, und die Feh­ler­mel­dung aus­le­sen.

Bei­spiel
Du möch­test zusätz­lich zur nume­ri­schen Kon­ver­tie­rung (aus Trick 4) für null-Werte die spe­zi­fi­sche Feh­ler­mel­dung. So erfährst du, war­um es nicht geklappt hat.

Zuerst wen­dest du nur try ohne other­wi­se an. Das Ergeb­nis wird für jede Zei­le in einer neu­en Spal­te (Preis­Nu­me­risch) als Record mit den Fel­dern HasEr­ror (WAHR / FALSCH) und Error oder Value gespei­chert. Error / Value je nach­dem, ob es zu einem Feh­ler kam (Error) oder die Funk­ti­on erfolg­reich war (Value).

Erwei­terst du die Records, erhältst du drei Spalten.

• HasEr­ror: Funk­ti­on erfolg­reich = TRUE, ansons­ten FALSE
• Value: Funk­ti­on erfolg­reich = Wert, ansons­ten null
• Error: Funk­ti­on fehl­ge­schla­gen = Feh­ler als Record, ansons­ten null

Klickst du in einen Record der Error-Spalte, kannst du dir die Details des Feh­lers anschau­en. Bspw. den Grund oder die Beschreibung.

HasEr­ror kann man gut in if-For­meln nut­zen, ist aber für uns erst­mal unin­ter­es­sant. Wir möch­ten Value & Error ger­ne in einer Spal­te ver­ei­nen und für Feh­ler die dazu­ge­hö­ri­ge Beschrei­bung (Mes­sa­ge) aus­ge­ben. Und das alles in einer simp­len For­mel.🙂 Dafür nutzt du fol­gen­de if-For­mel:

List.Contains(Record.FieldNames()) nimmt die Feld­na­men des Records in Preis­Nu­me­risch und prüft, ob es ein Feld mit der Bezeich­nung Error gibt. Ist das der Fall, erhal­ten wir den Fehler-Record, ansons­ten den rich­ti­gen Wert aus dem Value-Feld.

Nun ist Record nicht wirk­lich aus­sa­ge­kräf­tig. Daher fügen wir der then-Klau­sel das Anhäng­sel [Mes­sa­ge] an. Power Query zieht sich damit aus dem Error-Record die Beschrei­bung, wel­che im Mes­sa­ge-Feld ent­hal­ten ist.

Fazit

Daten sind dyna­misch, und damit auch die Her­aus­for­de­run­gen in der Daten­auf­be­rei­tung. Wenn du aber die hier vor­ge­stell­ten Power Query Hacks intel­li­gent ein­setzt, wirst du fest­stel­len, dass dei­ne Abfra­gen nicht nur sta­bi­ler wer­den, son­dern auch deut­lich ein­fa­cher zu war­ten sind. Du ver­bringst weni­ger Zeit mit dem Behe­ben von Feh­lern und mehr Zeit mit dem, was wirk­lich zählt: der Ana­ly­se dei­ner Daten (und Fehlern 😄).