Power BI-Error: ,,object reference not set to an instance of an object": Ursachen, Diagnose, Fix
Zusammenfassung
Der Fehler wirkt kryptisch, ist aber meist ein klarer Hinweis: Power BI greift auf etwas zu, das gerade nicht existiert (Null). Wenn du die Ursache isolierst, bekommst du wieder stabile Refreshes – und damit verlässliche KPIs statt manueller Excel-Reparaturen.
- Was der Fehler bedeutet und warum er auftritt
- Typische Ursachen in Power Query, Datenquellen und Treibern
- Diagnose-Schritte zur Reproduktion und Eingrenzung
- Konkrete Fixes + Checkliste und FAQs zu Aufwand/Voraussetzungen
Ziel: schnell wieder automatisiert aktualisierende Reports, die im Alltag funktionieren.
Der Power-BI-Fehler „power bi object reference not set to an instance of an object“ stoppt Refresh & Laden – so gehst du ihn sauber an.
Definition
„Object reference not set to an instance of an object“ ist eine .NET-Systemfehlermeldung (System.NullReferenceException), die auftritt, wenn eine Komponente auf ein nicht vorhandenes Objekt zugreift.
In Power BI ist das kein Fachbereichsfehler „in den Daten“, sondern typischerweise ein technischer Abbruch in Power BI Desktop, Power Query, einem Connector oder Treiber.
Einleitung
Du öffnest einen Bericht oder startest den Refresh und bekommst: „power bi object reference not set to an instance of an object“. Nervig, weil nichts mehr lädt. Mit einem strukturierten Vorgehen findest du schnell heraus, ob Power Query, die Datenquelle (z. B. Excel/SharePoint, Oracle, SAP BW) oder dein lokales Setup (Treiber/Version) der Auslöser ist.
Warum tritt der Fehler in Power BI so häufig auf?
Power BI hängt an vielen Bausteinen: Datei, Abfragen, Connectoren, Anmeldeinfos, Datenschutzeinstellungen, Treiber. Wenn an einer Stelle „Null“ zurückkommt (z. B. leere Tabelle statt erwartetem Objekt, ungültiger Pfad, fehlende Berechtigung), kann Power BI intern ohne saubere Fehlermeldung abbrechen und nur diese Standardexception zeigen.
Der praktische Effekt ist immer derselbe: Refresh fällt aus, Dashboards sind nicht aktuell und am Ende wird wieder manuell in Excel konsolidiert. Deshalb lohnt es sich, das Problem reproduzierbar einzugrenzen, statt „wild“ herumzuklicken.
Typische Ursachen (Power Query, Desktop, Datenquelle)
Nullwerte oder Strukturänderungen: Eine Spalte/ Tabelle fehlt plötzlich, ein Step referenziert ein Objekt, das es nicht mehr gibt (z. B. umbenannte Excel-Tabelle, geänderter SharePoint-Pfad).
Nicht initialisierte Logik in Power Query: Steps wie „Navigation“, „Expand“, „Changed Type“ greifen auf Felder zu, die in manchen Dateien/Zeilen nicht vorhanden sind.
Abfrage- und Connector-Probleme: Abgelaufene Anmeldetokens, geänderte Berechtigungen oder kaputte Treiber (Oracle-Client/ODAC, SAP .NET Connector, Office-/SharePoint-Komponenten) führen zu Abbrüchen statt klarer Fehlermeldungen.
Diagnose: So reproduzierst und isolierst du den Auslöser
Arbeite dich von „klein“ nach „groß“ vor. Ziel ist: eine einzige Query oder einen einzigen Step finden, der den Crash triggert.
1) Minimaltest im Power Query Editor
Öffne Power BI Desktop, dann „Daten transformieren“. Klicke jede betroffene Query einzeln an und geh Schritt für Schritt durch „Angewendete Schritte“. Sobald ein Step hängt oder Fehler wirft: Name des Steps notieren.
2) Reproduktion mit einer Kopie
Speichere eine Kopie der PBIX und deaktiviere testweise alles, was nicht nötig ist: entferne Queries oder setze sie auf „Laden deaktivieren“, bis der Fehler weg ist. So findest du die Problemstelle ohne Nebelkerzen.
3) Desktop vs. Quelle unterscheiden
Wenn Power Query im Editor sauber läuft, der Refresh aber beim Laden ins Modell crasht, ist oft ein Treiber/Connector oder eine Berechtigungs-/Datenschutzeinstellung beteiligt. Wenn es schon beim Öffnen der PBIX crasht, ist eher das lokale Desktop-Setup oder die Datei selbst betroffen.
Fix in Power Query: die drei häufigsten Reparaturen
A) Steps robust gegen fehlende Felder machen
Wenn Dateien oder Tabellen nicht immer gleich aufgebaut sind, baue Abfragen so, dass fehlende Spalten abgefangen werden (z. B. erst prüfen, dann expandieren). Das verhindert, dass ein einzelner Ausreißerfile den kompletten Refresh stoppt.
B) Navigation/Quelle neu setzen
Bei Excel- und SharePoint-Quellen ist die häufigste Ursache ein veralteter Pfad oder eine umbenannte Tabelle. Setze den Navigationsschritt neu, statt nur „irgendwie“ weiterzuarbeiten. Das ist meist schneller als Debugging im Modell.
C) Datentyp-Schritte reduzieren
„Changed Type“ auf viele Spalten kann bei unerwarteten Nulls/Strings kippen. Setze Typen gezielt auf die 3–5 wirklich kritischen Spalten oder verschiebe Typisierung später im Ablauf.
Datenquellen-Verbindungen prüfen: Excel, Oracle, SharePoint, SAP BW
Excel/SharePoint: Stimmt die Datei-URL wirklich (Web-URL, nicht der lokale Sync-Pfad)? Existieren Tabellen/Sheets noch? Sind Benennungen stabil? Vorteil: Wenn das sauber ist, laufen Refreshes zuverlässig ohne manuelles „Datei suchen“.
Oracle: Prüfe, ob der Oracle-Client/ODAC zur Architektur passt (64-bit ist Standard). Bei Mismatch funktionieren Verbindungen manchmal „halb“ und enden in unklaren Exceptions.
SAP BW: Achte auf passende Connector-Versionen und Berechtigungen. Wenn Queries nur für einzelne User funktionieren, ist das meist kein Power-BI-Thema, sondern ein Rollen-/SNC-/Connector-Setup.
Beispiel zur Veranschaulichung (ohne Screenshot)
Ein typisches Muster: Ein SharePoint-Excel wird ersetzt, die neue Datei heißt gleich, aber die interne Tabelle wurde von „Sales“ in „Sales_2026“ umbenannt. Power Query referenziert weiter die alte Objekt-ID aus dem Navigationsschritt. Ergebnis: „object reference…“. Fix: Navigationsschritt neu auswählen und danach die folgenden Steps prüfen.
Checkliste: Problem beheben und nachhaltig nachverfolgen
Kannst du die Query/den Step benennen, bei dem es kippt (nicht nur „Power BI ist kaputt“)?
Hast du Pfad/URL, Tabellen-/Sheetnamen und Berechtigungen der Quelle geprüft (Excel, SharePoint, Oracle, SAP BW)?
Sind Treiber/Connectoren und Power BI Desktop in passender Architektur installiert und aktuell?
Für die Nachverfolgung: notiere Ursache, Fix, betroffene Quelle und Datum. Das spart beim nächsten Mal Stunden und macht Updates planbar.
Wann externe Unterstützung sinnvoll wird
Wenn der Fehler nur in bestimmten Umgebungen auftritt (Desktop geht, Service/Gateway nicht), wenn mehrere Quellen beteiligt sind oder wenn ihr ohne klare Ownership an zig PBIX-Dateien rumdebuggt, lohnt sich Hilfe von außen. Dann geht es weniger um „Fehler wegklicken“, sondern um stabile Datenpipelines, klare Zuständigkeiten und ein Setup, das Refresh-Probleme früh sichtbar macht.
Fazit
„power bi object reference not set to an instance of an object“ ist fast immer ein Null-/Referenzproblem in Query, Connector oder lokalem Setup. Mit Isolation der betroffenen Query, robusteren Power-Query-Schritten und sauber geprüften Datenquellen bekommst du wieder stabile Aktualisierungen. Der größte Nutzen ist nicht technisch, sondern operativ: weniger manuelle Rettung in Excel und deutlich verlässlichere Zahlen für Entscheidungen.
FAQs (Kosten, Aufwand, Voraussetzungen)
Was kostet die Behebung?
In vielen Fällen kostet es nur Zeit für Diagnose und kleine Query-Anpassungen. Zusätzliche Kosten entstehen typischerweise nur dann, wenn Treiber/Connector-Setup, Gateway oder Berechtigungen grundsätzlich neu sauber aufgesetzt werden müssen.
Wie viel Aufwand ist realistisch?
Wenn du die Problem-Query bereits isoliert hast, ist der Fix oft überschaubar. Ohne Isolation kann es ausufern, weil du sonst an Symptomen arbeitest.
Woran messe ich den Erfolg?
Messbar ist es über stabile Refreshes (weniger Fehlversuche), eine kürzere Zeit bis zur Fehlerursache und weniger manuelle Workarounds (z. B. weniger Excel-Kopieren pro Woche/Monat).
Welche Voraussetzungen und Berechtigungen brauchst du?
Du brauchst Zugriff auf die Datenquelle (mindestens Leserechte), die Möglichkeit Anmeldedaten neu zu setzen und bei Oracle/SAP BW ggf. das Recht, Treiber/Connectoren installieren oder durch IT installieren zu lassen.






