> ## Documentation Index
> Fetch the complete documentation index at: https://docs.langdock.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Power BI Fehlerbehebung

> Behebe Power BI-Fehler in Langdock: fehlschlagende Abfragen, fehlende Build-Berechtigung, Fehler durch Row-Level Security, verzögerte Berechtigungsänderungen, XMLA- und Kapazitätsfehler sowie Abfragelimits.

Für die meisten Lösungen brauchst du einen Power BI-Admin oder den Owner des semantischen Modells. Wenn du Fachanwender bist, teile den passenden Eintrag mit dieser Person.

> [accordion] Jede Abfrage schlägt fehl, auch für User mit vollem Zugriff
>
> Aktiviere **REST-API des semantischen Modells zum Ausführen von Abfragen** unter **Mandanteneinstellungen** → **Integrationseinstellungen**. In der REST-Dokumentation von Microsoft heißt sie Dataset Execute Queries REST API. Ist die Einstellung auf eine Sicherheitsgruppe eingeschränkt, prüfe, ob der User darin ist. Jede Stufe braucht diese Einstellung, auch Fabric-Kapazität.
>
> Prüfe außerdem die tenantweite [Admin-Zustimmung](https://docs.langdock.com/de/admin/manage-integrations/integration-setup-guides/microsoft.md) für Langdock. Hat dein Langdock-Workspace nach dem Verbinden weitere Power BI-Aktionen aktiviert, verbindet sich der User einmal neu, um die neuen Berechtigungen zu erteilen.

> [accordion] Workspace oder semantisches Modell wird nicht gelistet
>
> Langdock findet nur Elemente, die das angemeldete Microsoft-Konto sehen kann. Gib dem User Workspace **Viewer** oder höher. Modelle im **My Workspace** einer Person sieht nur diese Person, und du kannst Gruppen dort keinen Zugriff geben. Verschieb sie daher in einen geteilten Workspace.

> [accordion] Abfragen schlagen fehl mit "the dataset was not found or you do not have the required permissions"
>
> Dieser 404-Fehler heißt: Der User hat Workspace-Zugriff, aber kein **Build** auf dem semantischen Modell. Berichte und Modelle auflisten klappt weiterhin, deshalb wirkt die Verbindung gesund. **Execute query**, **Get table sample**, **Get table count** und Schema-Aktionen schlagen aber fehl.
>
> Vergib Build auf dem Modell, am besten an die Sicherheitsgruppe des Users. Bis die Änderung greift, kann etwa eine Stunde vergehen. Siehe [Viewer mit Build oder nur Viewer](https://docs.langdock.com/de/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#viewer-mit-build-oder-nur-viewer).

> [accordion] Eine Abfrage auf einem Modell mit Row-Level Security schlägt fehl
>
> Hat das Modell Row-Level Security und ist der User in keiner Sicherheitsrolle, lehnt Power BI die Abfrage ab, statt leere Ergebnisse zu liefern. Langdock zeigt derzeit den allgemeinen Fehler `Query execution failed (401)`, der wie eine defekte Verbindung aussehen kann.
>
> Bitte den Owner des Modells, den User oder eine seiner Gruppen zur passenden Rolle hinzuzufügen. Warte dann, bis die Änderung greift, wie im nächsten Eintrag beschrieben.

> [accordion] Eine Berechtigungs- oder Rollenänderung wirkt noch nicht
>
> Power BI wendet die bisherigen Rechte eines Users an, bis sein Zugriffstoken erneuert wird. Das kann etwa eine Stunde dauern. Das gilt für Workspace-Zugriff, Build und Änderungen an RLS-Rollen. Solange eine Änderung greift, können manche Aktionen klappen, während andere schon fehlschlagen. Die Kapazität zu pausieren und fortzusetzen hilft nicht.
>
> Warte oder bitte den User, seine Microsoft-Verbindung in Langdock neu herzustellen, bevor du erneut testest.

> [accordion] Manche User sehen mehr Daten als erwartet
>
> Nutzt das Modell Row-Level Security, umgehen Workspace **Contributor**, **Member** und **Admin** sowie Schreibberechtigung auf dem Modell diese. Gib Consumern stattdessen Workspace **Viewer** plus **Build**. Siehe [Workspace-Rollen und Row-Level Security](https://docs.langdock.com/de/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#workspace-rollen-und-row-level-security).
>
> Sehen alle User eines geteilten Agenten dieselben Daten, nutzt der Agent eine vorausgewählte Verbindung und läuft als deren Owner. Stell die Power BI-Aktionen so um, dass jeder User sein eigenes Konto verbindet. Siehe [Geteilte Agenten und Workflows](https://docs.langdock.com/de/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#geteilte-agenten-und-workflows).

> [accordion] Manche User sehen andere Zeilen als andere
>
> Nutzt das Modell Row-Level Security, funktioniert RLS damit wie vorgesehen. Um einen konkreten Fall zu prüfen, führe dieselbe Abfrage in Power BI als dieser User aus und prüfe die Microsoft Entra-Gruppenmitgliedschaft hinter den Sicherheitsrollen.

> [accordion] Eine Anfrage schlägt fehl mit "not on dedicated capacity"
>
> Pro-Workspaces haben keinen XMLA-Endpunkt. Standard-DAX-Abfragen sowie Schema, Measures und Beziehungen von Standardmodellen funktionieren dort trotzdem. Dieser Fehler erscheint auf Pro, wenn die Abfrage eine DMV- (`$SYSTEM.*`), MDX- oder `INFO.*`-Abfrage außer `INFO.VIEW.*` ist. Stell stattdessen eine Standard-DAX-Frage, oder verschieb das Modell in einen Workspace mit XMLA. Siehe [Was XMLA erfordert](https://docs.langdock.com/de/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#was-xmla-erfordert).
>
> Ist das Modell eine Live-Verbindung zu Analysis Services, hilft dir der nächste Eintrag.
>
> Prüfe in einem Workspace mit Kapazität in dieser Reihenfolge:
>
> 1. Die Mandanteneinstellung **XMLA-Endpunkte und "In Excel analysieren" bei lokalen semantischen Modellen zulassen** ist aktiv, und der User ist in ihrer Sicherheitsgruppe, falls sie eingeschränkt ist.
> 2. Der **XMLA-Endpunkt** der Kapazität steht auf **Schreibgeschützt** oder **Lesen und schreiben**, nicht auf **Deaktiviert**.
> 3. Der Workspace ist dieser Kapazität zugewiesen, und die Kapazität läuft. Bei Premium Per User hat der User eine PPU-Lizenz.
> 4. Der User hat **Build** auf dem semantischen Modell.

> [accordion] Jede Abfrage auf einem Modell mit Live-Verbindung zu Analysis Services schlägt fehl
>
> Semantische Modelle, die Live-Verbindungen zu Azure Analysis Services oder SQL Server Analysis Services sind, kann Langdock nicht abfragen. Microsoft unterstützt für sie weder die Abfrage-API noch XMLA. Auf Pro sagt der Fehler, dass XMLA nicht verfügbar ist. Auf Kapazität heißt es, die Datenbank existiere nicht oder dir fehle die Berechtigung. Das Modell auf Kapazität zu verschieben oder Berechtigungen zu ändern hilft nicht.
>
> Wenn du die Daten in Langdock nutzen willst, hoste das Modell stattdessen in Power BI oder Fabric. Siehe [Live-Verbindungen zu Analysis Services](https://docs.langdock.com/de/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#live-verbindungen-zu-analysis-services).

> [accordion] Measure-Formeln sind leer
>
> Power BI liefert Measure-Formeln nur über XMLA und nur an User mit Schreibberechtigung auf dem Modell. Viewer mit Build bekommen Namen und Beschreibungen von Measures. In Pro-Workspaces bekommt niemand Formeln über Langdock. Siehe [Was XMLA erfordert](https://docs.langdock.com/de/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#was-xmla-erfordert).

> [accordion] Schema oder Measures schlagen in einem Premium-Per-User-Workspace fehl und fordern zum Neuverbinden auf
>
> XMLA in einem Premium-Per-User-Workspace funktioniert nur für User mit PPU-Lizenz. Für einen Pro-User schlagen **Get dataset schema**, **Get semantic model measures** und andere XMLA-basierte Aktionen fehl. Langdock meldet derzeit ein ungültiges oder abgelaufenes Zugriffstoken und fordert zum Neuverbinden auf. Der ursprüngliche Fehler am Ende der Meldung ist `PowerBINotLicensedException`, und Neuverbinden hilft nicht.
>
> Abfragen, Tabellen-Samples und Auflisten funktionieren für diesen User weiterhin. Gib Buildern, die XMLA brauchen, eine PPU-Lizenz, oder nutze einen Workspace auf Fabric-Kapazität.

> [accordion] Berichtsexport schlägt fehl
>
> **Export report to file** schlägt auf Pro und auf Premium Per User fehl. Der Bericht braucht einen Workspace auf Fabric-, Power BI Premium- oder Embedded-Kapazität.
>
> **Export paginated report** schlägt auf Pro fehl. Auf Premium Per User läuft der Export, begrenzt auf eine Anfrage pro User alle fünf Minuten, und auch auf Fabric-, Power BI Premium- oder Embedded-Kapazität. Ein paginierter Bericht, der schon auf Premium Per User liegt, muss nicht in einen Workspace mit Kapazität umziehen.
>
> Stell stattdessen eine Frage zu den Daten, oder verschieb einen Bericht, der sich nicht exportieren lässt, in einen Workspace mit Kapazität.

> [accordion] Der Trigger Dataset refresh completed schlägt fehl
>
> Der Aktualisierungsverlauf braucht Workspace **Contributor** oder höher, oder der User ist Owner des semantischen Modells. Viewer mit Build können diesen Trigger nicht nutzen.

> [accordion] List dataset tables schlägt fehl
>
> **List dataset tables (Push API only)** funktioniert nur für Push-Datasets. Nutze für Import-, DirectQuery- und Composite-Modelle **Get dataset schema**, oder bitte Langdock, das Modell direkt abzufragen.

> [accordion] Ein Ergebnis ist zu groß
>
> Microsoft begrenzt, wie viele Daten eine einzelne Abfrage liefern kann. Bitte Langdock um eine gezieltere Abfrage, zum Beispiel mit Filtern oder Aggregation. Siehe Microsofts [Execute Queries limitations](https://learn.microsoft.com/de-de/rest/api/power-bi/datasets/execute-queries-in-group#limitations).

> [accordion] Abfragen schlagen mit zu vielen Anfragen fehl
>
> Microsoft begrenzt, wie viele Abfragen jeder User pro Minute senden darf. Warte eine Minute und versuch es erneut. Agenten und Workflows, die in Schleifen abfragen, können diese Grenze erreichen.

> [accordion] Kapazität ist pausiert oder gedrosselt
>
> Starte die Kapazität wieder, oder warte und versuch es erneut, wenn Fabric drosselt. Hält das an, bitte den Kapazitätsadministrator, die [Capacity Metrics App](https://learn.microsoft.com/de-de/fabric/enterprise/metrics-app) zu prüfen. Pro-Workspaces sind nicht betroffen.

## Weiterführende Administration

Aktuelles Verhalten zu Berechtigungen, Lizenzen und XMLA findest du in der Dokumentation von Microsoft:

* [Execute Queries REST API](https://learn.microsoft.com/de-de/rest/api/power-bi/datasets/execute-queries-in-group)
* [Semantic model permissions](https://learn.microsoft.com/de-de/power-bi/connect-data/service-datasets-permissions)
* [Build permission for shared semantic models](https://learn.microsoft.com/de-de/power-bi/connect-data/service-datasets-build-permissions)
* [Row-level security with Power BI](https://learn.microsoft.com/de-de/fabric/security/service-admin-row-level-security)
* [Semantic model connectivity with the XMLA endpoint](https://learn.microsoft.com/de-de/fabric/enterprise/powerbi/service-premium-connect-tools)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.