Power BI Error 2147467259: Ursachen, Kontext und Troubleshooting-Checkliste

Definition

Power BI Error 2147467259 (Error code -2147467259 / 0x80004005) ist ein unspezifischer Verbindungs- oder Zugriffsfehler, der beim Laden oder Aktualisieren von Daten auftritt. Er ist kein DAX- oder Visualisierungsfehler, sondern entsteht typischerweise in Treibern, Credentials, Gateway, Netzwerk oder der Datenquelle selbst.

Einleitung

Wenn der Refresh im Power BI Service scheitert, wird aus „Dashboard“ schnell wieder „Excel-Handarbeit“. Der Code 2147467259 ist dabei besonders nervig, weil er wie ein Sammelbecken für verschiedene Ursachen wirkt. Mit einem sauberen Troubleshooting sparst du Zeit, bekommst wieder verlässliche Zahlen und kannst geplante Refreshes stabil betreiben.

In welchen Kontexten tritt der Fehler typischerweise auf?

In der Praxis sieht man den Fehler fast immer in einem dieser Fälle:

• Datenimport/Refresh in Power BI Desktop oder beim geplanten Refresh im Service.
• On-premises Data Gateway (Gateway offline, falsche Zuordnung, Credentials im Gateway passen nicht).
• Datenquellen mit Treiber-Layer: ODBC/OLE DB, Microsoft Access (MDB/ACCDB), MySQL.

Typische Ursachen je Datenquelle (Access, ODBC, MySQL, Web, Gateway)

Der gleiche Error code kann je nach Quelle etwas anderes bedeuten. Die häufigsten Muster:

• Microsoft Access (MDB/ACCDB): Zugriff auf Pfad/Datei fehlt, Datei ist gesperrt, oder die Microsoft Access Database Engine (32/64 Bit) passt nicht zur Umgebung.
• ODBC/OLE DB: DSN verweist auf falschen Server, Treiber-Version ist inkompatibel, oder der Windows-Dienstaccount (Gateway) sieht die DSN/Quelle nicht.
• MySQL: abgelaufene Nutzerrechte, SSL/Parameter-Änderungen, Timeouts bei großen Abfragen oder Verbindung wird serverseitig beendet.

Bei Webdatenquellen (Power Query mit Web.Contents oder Web.BrowserContents) sind es oft Authentifizierung (Anonymous vs. Organizational), geänderte Endpunkte oder zu langsame Antworten.

Power BI Desktop vs. Power BI Service: der wichtigste Unterschied

Power BI Desktop läuft unter deinem Benutzerkonto. Der Power BI Service refresht aber entweder über Microsofts Cloud-Connectoren oder über das On-premises Data Gateway – und dann zählt das Konto, das dort konfiguriert ist.

• Desktop funktioniert, Service nicht: sehr oft Gateway/Credentials/Permissions-Problem (anderer Account, anderer Netzwerkpfad).
• Service funktioniert, Desktop nicht: eher lokales Treiber-/Clientproblem (ODBC, Access Engine, lokale Zertifikate).
• Beides kaputt: Quelle selbst, Netzwerk oder Query/Timeout.

Troubleshooting-Checkliste: sinnvolle Reihenfolge

Arbeite die Schritte in genau dieser Reihenfolge ab – so vermeidest du „Try & Error“.

1) Error message vollständig lesen und Kontext sichern

Notiere: Quelle (Access/MySQL/Web), ob Import oder DirectQuery, ob Service oder Desktop, Zeitpunkt, und ob es ein wiederkehrendes issue ist oder „seit June nach Update“.

2) Permissions & Credentials prüfen (häufigster Fix)

In Power BI Desktop: Datei > Optionen und Einstellungen > Datenquelleneinstellungen. Dort die betroffene Datenquelle auswählen, Berechtigungen prüfen und bei Bedarf löschen und neu setzen. Im Service zusätzlich im Dataset die Credentials prüfen (Authentication-Methode passend wählen).

3) Gateway prüfen (wenn On-Premises im Spiel ist)

Im Power BI Service: Dataset-Einstellungen → Gateway-Verbindung. Prüfe, ob das richtige Gateway ausgewählt ist, ob es online ist und ob die Datenquellen-Zuordnung exakt passt (Server-/Database-Name, Pfade, DSN).

4) Quelle/Treiber/Bitness verifizieren

Bei Access/ODBC: stimmt 32/64 Bit zwischen Treiber und Umgebung? Bei DSN: im richtigen ODBC Data Source Administrator (odbcad32.exe) schauen und Verbindung testen. Bei MySQL: Treiber/Connector-Version prüfen und Testconnect außerhalb von Power BI durchführen.

5) Timeouts und langsame Queries adressieren

Wenn das underlying error auf Timeout oder „connection closed“ hindeutet: Query reduzieren, Filter früher setzen, inkrementell laden (wo sinnvoll) oder Timeouts in Quelle/Gateway/Server prüfen. Ziel ist nicht „mehr warten“, sondern stabiler Refresh.

Typische Meldungen und was sie fürs Troubleshooting bedeuten

Der Code kommt oft zusammen mit Hinweisen, die die Richtung vorgeben:

• „Underlying error“ / „Microsoft Mashup“ / „Mashup ValueError“: Problem entsteht im Power Query Layer (Auth, Schritte, Web.Contents, Treiber).
• „DM_ErrorDetailNameCode“ oder „code dm“: Service/Refresh-Kontext – prüfe Gateway, Dataset-Credentials und den Refresh-Verlauf.
• „Accessing … denied“: klares Permissions-Thema (Dateipfad, Datenbankrolle, Service-Account).

Wie du Netzwerk- und Serverprobleme erkennst

Netzwerkprobleme sehen oft so aus: Refresh bricht sporadisch ab, mal geht’s, mal nicht. Typische Signale sind Verbindungsabbrüche, „forcibly closed“ oder wechselnde Laufzeiten.

• Teste Erreichbarkeit vom Gateway-Server zur Quelle (nicht von deinem Laptop).
• Prüfe Firewalls, Proxy, VPN-Abhängigkeiten und ob ein Server nachts neu startet.
• Bei Datei-Quellen: UNC-Pfade statt Laufwerksbuchstaben verwenden, und Zugriffe für den Gateway-Dienstaccount sauber setzen.

Diagnose: Wo findest du Logs und Refresh-Details?

Für zielgerichtete Analyse brauchst du Belege, nicht Bauchgefühl:

• Power BI Service: Refresh-Historie im Dataset (Fehlerdetails, Zeit, Gateway-Bezug).
• Power BI Desktop: Power Query Schritt-für-Schritt testen; bei Bedarf Diagnoseoptionen/Protokolle nutzen, um die genaue Stelle zu sehen.
• Gateway: Gateway-Status, Version, und (falls nötig) Gateway-Logs zur Fehlerzeit auswerten.

Verifikation nach dem Fix (damit es nicht nächste Woche wieder knallt)

Nach der Behebung solltest du nicht nur „einmal Refresh drücken“, sondern stabilisieren:

• Manueller Refresh im Service + mindestens ein geplanter Refresh erfolgreich.
• Credentials dokumentiert (welches Konto, welche Methode, Ablaufdatum/Rotation).
• Refresh-Dauer und Fehlerrate beobachtet: Ziel ist reproduzierbare Aktualisierung, nicht nur ein Lucky Shot.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn der Fehler deine Steuerung blockiert (z. B. Cashflow/Management-Reporting), wenn Gateway/ODBC/Access-Setups historisch gewachsen sind oder wenn mehrere Quellen (Web, MySQL, Fileserver, ODBC) zusammenspielen. Dann spart ein strukturiertes Setup inkl. Permissions-Konzept und stabiler Refresh-Architektur meist deutlich mehr Zeit, als man im „Community powerbi“-Pingpong verliert.