Jede Abfrage schlägt fehl, auch für User mit vollem Zugriff
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 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.
Workspace oder semantisches Modell wird nicht gelistet
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.
Abfragen schlagen fehl mit "the dataset was not found or you do not have the required permissions"
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.
Eine Abfrage auf einem Modell mit Row-Level Security schlägt fehl
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.Eine Berechtigungs- oder Rollenänderung wirkt noch nicht
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.
Manche User sehen mehr Daten als erwartet
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.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.
Manche User sehen andere Zeilen als andere
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.
Eine Anfrage schlägt fehl mit "not on dedicated capacity"
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.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:- 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.
- Der XMLA-Endpunkt der Kapazität steht auf Schreibgeschützt oder Lesen und schreiben, nicht auf Deaktiviert.
- Der Workspace ist dieser Kapazität zugewiesen, und die Kapazität läuft. Bei Premium Per User hat der User eine PPU-Lizenz.
- Der User hat Build auf dem semantischen Modell.
Jede Abfrage auf einem Modell mit Live-Verbindung zu Analysis Services schlägt fehl
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.
Measure-Formeln sind leer
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.
Berichtsexport schlägt fehl
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.
Der Trigger Dataset refresh completed schlägt fehl
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.
List dataset tables schlägt fehl
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.
Ein Ergebnis ist zu groß
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.
Abfragen schlagen mit zu vielen Anfragen fehl
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.
Kapazität ist pausiert oder gedrosselt
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 zu prüfen. Pro-Workspaces sind nicht betroffen.