Fehlerbehebung der Git-Integration für die Entwicklung von Fabric-Lagerhäusern

Zutreffend für: ✅ Warehouse in Microsoft Fabric

Dieser Artikel enthält Themen zur Fehlerbehebung zur Entwicklung und Bereitstellung von Fabric Data Warehouse mit der integrierten Git-Integration von Fabric.

Important

Dieses Feature befindet sich in der Vorschauphase.

Verweise auf die eigenen Objekte des Lagers unter Verwendung eines dreiteiligen Namens

Ein Objekt kann ein anderes Objekt im selben Warehouse mit einem dreiteiligen Namen referenzieren. [warehouse_name].[schema_name].[object_name]

Die dreiteilige Benennung dient dazu, ein anderes Lager zu referenzieren. Wenn der Datenbankteil das aktuelle Warehouse benennt, behandelt der Build die Referenz als extern, und das Objekt wird im Modell zweimal definiert.

Entfernen Sie den Datenbankteil aus den Referenzen auf die eigenen Objekte des Warehouses:

-- Fails: the warehouse is named MyWarehouse and references itself by name
CREATE VIEW [Sales].[CustomerSummary] AS
SELECT c.[CustomerId], c.[OrderDate]
FROM [MyWarehouse].[Sales].[Customers] AS c;

-- Works
CREATE VIEW [Sales].[CustomerSummary] AS
SELECT c.[CustomerId], c.[OrderDate]
FROM [Sales].[Customers] AS c;

Nur die Verweise auf die eigenen Objekte des Lagers müssen geändert werden. Echte Datenbankübergreifende Verweise auf andere Warehouses, wie [Other_Warehouse].[Sales].[Orders], werden unterstützt und sollten as-isbleiben.

Important

Verwenden Sie dreiteilige Benennung (database.schema.object) nur für Cross-Warehouse- oder Cross-SQL-Analytics-Endpunktreferenzen, nicht für Objekte innerhalb desselben Warehouses. Das Selbstreferenzieren von Objekten im selben Warehouse durch dreiteilige Benennung ist keine Standardmodellierungspraxis und kann unbeabsichtigte externe Verweise erzeugen.

Wo möglich, modellieren Sie Objekte mit zweiteiliger Benennung (schema.object) statt dreiteiliger Benennung, selbst für Selbstreferenzen innerhalb desselben Lagers. Diese Konvention verbessert die Konsistenz zwischen den Client-Tools und vermeidet die durch dreiteilige Referenzen eingeführte Mehrdeutigkeiten.

Veraltete .sqlproj im Git-Repository

Das Git-Repository kann eine .sqlproj Datei enthalten, die auf eine ältere Microsoft.Build.Sql SDK-Version referenziert. Das ältere SDK erkennt neuere Fabric Data Warehouse Syntax wie IDENTITY Spalten und CLUSTER BY.

Dieses Problem betrifft Repositories, deren Inhalte vor dem Umzug des Lagers auf das aktuelle Definitionsformat festgelegt wurden. Die häufigsten Situationen, die zu einer veralteten .sqlproj-Datei führen, sind:

  • Einen neuen Arbeitsbereich mit einem bestehenden Repository verbinden. Das Lager wird aus dem erstellt, was dort eingewiesen ist.
  • Ich habe mich auf einen neuen Arbeitsplatz ausgeweitet.
  • Wiederherstellung eines gelöschten Lagers aus Git.
  • Synchronisierung von Git unmittelbar, nachdem das Warehouse auf das aktuelle Definitionsformat umgestellt wurde, bevor jegliche Synchronisation in die andere Richtung ausgeführt wurde.

Warehouses, die nicht auf das aktuelle Definitionsformat verschoben wurden, sind nicht betroffen, weil die ältere Projektdatei nicht zum Aufbau verwendet wird.

Wie man die .sqlproj SDK-Version bestätigt

Öffnen Sie die .sqlproj Datei des Lagers im Repository und prüfen Sie die SDK-Version im XML:

<Sdk Name="Microsoft.Build.Sql" Version="2.2.0" />

Eine Version, die hinter dem aktuellen Microsoft zurückliegt. Die Build.SQL-Paketversion zeigt eine veraltete Projektdatei an. Zum Beispiel, wenn deine Version mit 0.1.beginnt. Weitere Informationen finden Sie unter Microsoft. Build.SQL und Vorlagen-Releases.

Update .sqlproj SDK Version Option A: Warehouse zuerst mit Git synchronisieren

Wenn das Warehouse bereits im Arbeitsbereich existiert und gesund ist, committe vom Arbeitsbereich zu Git, bevor du in die andere Richtung synchronisierst. Diese Aktion generiert die Projektdatei mit der aktuellen SDK-Version erneut, danach funktioniert die Synchronisierung mit Git normal.

Diese Option ist, wo verfügbar, bevorzugt, da sie die gesamte Definition aktualisiert und nicht nur das SDK-Attribut.

Das Lager muss bereits im aktuellen Definitionsformat liegen, damit diese Option funktioniert. Wenn nicht, upgrade es zuerst im Fabric Git-Panel und commet dann zu Git. Das Committen aus einem Warehouse, das noch im älteren Definitionsformat ist, schreibt das ältere Format zurück ins Repository und aktualisiert die SDK-Version nicht, sodass die nächste Synchronisation genauso fehlschlägt. Wenn du nicht upgraden kannst, nutze stattdessen die Reparaturoption B .

Update .sqlproj SDK Version Option B: Aktualisieren Sie die .sqlproj-Datei direkt in Git

Nutzen Sie diese Option, wenn das Warehouse im Ziel-Arbeitsbereich noch nicht existiert, zum Beispiel wenn Sie einen neuen Arbeitsbereich mit einem bestehenden Repository verbinden, sich erweitern oder ein gelöschtes Warehouse wiederherstellen. In diesen Fällen gibt es kein Lagerhaus zum Synchronisieren, daher ist Option A nicht verfügbar.

Bearbeiten Sie die .sqlproj Datei im Repository, um das neueste Microsoft zu verwenden. Build.SQL-Paketversion verwenden und die Änderung committen. Beispiel:

<!-- Before -->
<Sdk Name="Microsoft.Build.Sql" Version="0.1.19-preview" />

<!-- After -->
<Sdk Name="Microsoft.Build.Sql" Version="2.2.0" />

Das Ausführen eines Exports oder eines Diffs allein aktualisiert die Projektdatei nicht. Die Datei wird nur umgeschrieben, wenn ein Commit vom Arbeitsbereich zu Git abgeschlossen ist oder wenn man sie manuell bearbeitet.

Unqualifizierte Spalten in Objekten, die auf zwei oder mehr Tabellen in einem anderen Warehouse verweisen

Stellen Sie immer Tabellenaliase bereit und verwenden Sie, wenn Sie auf Spalten in T-SQL-Abfragen referenzieren.

  • Wenn eine T-SQL-Abfrage zwei oder mehr Tabellen in einem anderen Warehouse referenziert, kann der Build eine Spalte, die ohne Tabellenalias geschrieben wurde, nicht zu einer bestimmten Tabelle validieren. Die Tabellen müssen keinen Spaltennamen teilen, damit diese Mehrdeutigkeit existiert. Diese Mehrdeutigkeit existiert im Validierungs-Build.
  • Diese Mehrdeutigkeit betrifft T-SQL-Abfragen innerhalb von Objekten, die auf zwei oder mehr Tabellen in einem anderen Warehouse innerhalb desselben Statement-Body verweisen.
  • Diese Mehrdeutigkeit wirkt sich nicht auf T-SQL-Abfragen innerhalb von Objekten aus, die nur auf eine Tabelle in einem anderen Warehouse verweisen, denn bei einer einzigen Quelle gibt es nichts, zwischen dem man mehrdeutig sein müsste.
  • Diese Mehrdeutigkeit betrifft nicht T-SQL-Abfragen, die vollständig in einem Warehouse bleiben.

Im folgenden Beispiel hat finamenur fieldinfo , sodass das SQL gültig ist und korrekt gegen das Warehouse ausgeführt wird, aber im Validierungs-Build besteht eine Mehrdeutigkeit.

-- Fails: two tables from another warehouse, and 'finame' isn't alias-qualified
CREATE PROCEDURE [dbo].[LoadFieldInfo] AS
SELECT finame
FROM   [OtherWarehouse].[halo].[fieldinfo] AS f
INNER JOIN   [OtherWarehouse].[halo].[lookup]    AS l ON f.[id] = l.[id];

Füge jedem Spaltenreferenzen im betroffenen Objekt ein Tabellenalias hinzu:

-- Works: every column carries its table alias
CREATE PROCEDURE [dbo].[LoadFieldInfo] AS
SELECT f.[finame]
FROM   [OtherWarehouse].[halo].[fieldinfo] AS f
INNER JOIN   [OtherWarehouse].[halo].[lookup]    AS l ON f.[id] = l.[id];

Inkonsistente Großschreibung von Schemanamen

Dein Lager kann eine groß- und kleinschreibungsunsensitive Sortierung verwenden, also sales sind und Sales dasselbe Schema, aber deine Skripte können es an unterschiedlichen Stellen in beide Richtungen schreiben. Case-insensitive Datenbanken haben das immer akzeptiert, daher ist die Inkonsistenz meist langjährig und harmlos.

Wenn deine Skripte zwei oder mehr verschiedene Objekte im selben Schema eines anderen Lagers referenzieren und dieses Schema in jeder Referenz unterschiedlich schreiben, generiert der Build für jede Schreibweise eine CREATE SCHEMA Anweisung. Dieses Problem betrifft nur Lagerhäuser, die auf ein anderes Lager verweisen und eine kleinschreibungsunsensitive Sortierung verwenden.

  • Standardmäßig verwenden Latin1_General_100_BIN2_UTF8Lagerhäuser in Fabric , eine groß- und kleinschreibungsabhängige Sortierung. Fallsensitive Lagerhäuser sind nicht betroffen. In diesen Lagern gibt es Sales zwei verschiedene Schemata, sales ob Sie das beabsichtigen oder nicht.
  • Eine fallunsensitive Datenbank kann nicht sowohl sales als auch Salesenthalten. Das Duplikat entsteht nur durch die unterschiedlichen Schreibweisen in deinem SQL-Text.

Überprüfe die Lagersortierung und die ModelCollation Angaben in der .sqlproj Datei. Achten Sie auf CI (groß- und schreibunempfindlich) oder CS (großschreibungssensitiv).

<ModelCollation>1033, CI</ModelCollation>   <!-- case-insensitive: affected -->
<ModelCollation>1033, CS</ModelCollation>   <!-- case-sensitive: not affected -->

Beheben

Um inkonsistente Schemaname-Großschreibung in deinen Warehouse-Objektdefinitionen zu identifizieren, vergleiche die Großschreibung des im Fehler genannten Schemas über alle deine Skripte hinweg. Achten Sie auf zwei Cross-Warehouse-Referenzen auf dasselbe Schema, die sich nur im Fall unterscheiden.

Verwenden Sie überall eine einheitliche Großschreibung, die mit dem tatsächlichen Schemanamen im referenzierten Warehouse übereinstimmt. Zum Beispiel verwenden Sie nur Sales oder nur sales.

-- Fails: two objects in the same schema, referenced with different capitalization
CREATE VIEW [dbo].[v_one] AS SELECT * FROM [OtherWarehouse].[sales].[Orders];
GO
CREATE VIEW [dbo].[v_two] AS SELECT * FROM [OtherWarehouse].[Sales].[Customers];

-- Works: same capitalization in both references
CREATE VIEW [dbo].[v_one] AS SELECT * FROM [OtherWarehouse].[Sales].[Orders];
GO
CREATE VIEW [dbo].[v_two] AS SELECT * FROM [OtherWarehouse].[Sales].[Customers];

Dieses Problem hat man, wenn man zwei verschiedene Objekte mit zwei unterschiedlichen Schema-Großbuchstaben hat. Zwei Verweise auf dasselbe Objekt mit unterschiedlicher Großschreibung sind korrekt gefaltet und versagen nicht.

Spaltenkollation

Wenn die COLLATE Klausel einer Spalte explizit dieselbe Kollierung wie die Standard-Kollierung des Lagers angibt, behandelt die Schema-Extraktion von Fabric (DacFx-basiert) die explizite Kollation als gleichbedeutend damit, gar keine Einheit anzugeben. In diesem Fall:

  • Die explizite COLLATE Klausel erscheint nicht in der Item-Definition, die in das Git-Repository extrahiert wurde.
  • Die Spalte wird bei Git-Änderungen, Updates oder Deployment-Pipeline-Vergleichen nicht als Unterschied angezeigt, da es keinen effektiven Unterschied zur Standard-Sortierung des Lagers gibt.

Nur Spalten, deren Sortierung von der Standard-Kollierung des Lagers abweicht, behalten eine explizite COLLATE Klausel in der Quellcodekontrolle, und nur Änderungen an der Sortierung dieser Spalten erscheinen als Unterschiede.

Betrachten wir zum Beispiel ein Warehouse, dessen Sortierung folgt Latin1_General_100_CI_AS_KS_WS_SC_UTF8:

CREATE TABLE dbo.MixedCollationExample
(
    CustomerId      INT             NOT NULL,
    FirstName       VARCHAR(100)    NOT NULL,                                               -- inherits warehouse collation
    LastNameBin     VARCHAR(100)    COLLATE Latin1_General_100_BIN2_UTF8 NOT NULL,          -- column override, differs from warehouse collation
    Email           VARCHAR(256)    COLLATE Latin1_General_100_CI_AS_KS_WS_SC_UTF8 NULL     -- explicit collation, matches warehouse collation
);
  • FirstName hat keine explizite Kollation und erbt die Standard-Kollation des Lagers.
  • LastNameBin hat eine explizite Kollierung, die sich von der Standard-Kollierung des Lagers unterscheidet, sodass sie in der extrahierten Definition erhalten bleibt und bei Änderungen immer in Vergleichen erscheint.
  • Email hat eine explizite Kollation, die mit der Standard-Kollektion des Lagers übereinstimmt. Obwohl die COLLATE Klausel im T-SQL vorhanden ist, erscheint sie nicht in der Git-extrahierten Definition oder in Git- oder Deployment-Pipeline-Vergleichen, weil sie dem Standard entspricht.

Mehrdeutige Spaltenfehler mit doppelten Kandidatenobjekten

Das Committen oder Aktualisieren von Git kann mit einem mehrdeutigen Spaltenfehler scheitern, dessen Kandidatenliste einen :: Separator enthält, zum Beispiel:

SQL71501: View: [dbo].[SchoolSummary] contains an unresolved reference to an object.
Either the object does not exist or the reference is ambiguous because it could refer
to any of the following objects: [dbo].[SchoolSummary].[NCESID] or
[dbo].[SchoolSummary].[ss]::[NCESID].

Der Separator :: unterscheidet diesen Fehler von der echten Mehrdeutigkeit, die in Unqualifizierten Spalten in Objekten beschrieben wird, die auf zwei oder mehr Tabellen in einem anderen Lager verweisen. Das Hinzufügen eines Tabellen-Alias löst es nicht, da der Alias in der Kandidatenliste erscheint und der Fehler trotzdem auftritt.

  1. Schließen Sie zunächst diese beiden häufigeren Ursachen aus:

    • Ein wirklich fehlendes oder falsch benanntes Objekt. Wenn dasselbe Commit oder Update auch eine ungelöste Referenz auf ein bestimmtes fehlendes Objekt meldet, wie zum Beispiel SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable], korrigieren Sie diese Referenz zuerst. Die Kandidaten :: werden in der Regel auch klar.
    • Eine wirklich mehrdeutige Kolumne. Wenn eine unqualifizierte Spalte über einer Verbindung von zwei Quellen ausgewählt wird, die beide eine Spalte mit diesem Namen offenlegen, qualifizieren Sie die Spalte beispielsweise mit ihrem Tabellenalias.a.[NCESID] SQL Server würde diese Abfrage ebenfalls ablehnen, daher ist sie nicht spezifisch für Git-Integration.

  2. Wenn jedes referenzierte Objekt existiert und keine Spalte wirklich mehrdeutig ist, sind die Kandidaten :: ein bekanntes Problem in der Validierung, die während Commits und Updates von Git ausgeführt wird und vom Produktteam verfolgt wird. Versuche diese Workarounds, in der Reihenfolge:

    1. Ersetzen Sie SELECT * interne CTEs und abgeleitete Tabellen durch eine explizite Spaltenliste.
    2. Teile die Ansicht so auf, dass jede mehrdeutige Quelle in ihrer eigenen Ansicht definiert ist, und verweise auf diese Ansicht, anstatt die zugrundeliegende Abfrage zu wiederholen.
    3. Vermeiden Sie es, mit einer anderen dynamisch geformten Quelle in derselben Aussage zu verbinden OPENROWSET(BULK ...) .

Wenn keiner davon den Fehler behebt, sammeln Sie die Definition des im Fehler genannten Objekts und eröffnen Sie eine Supportanfrage. Für spezifische Einschränkungen für Bereitstellungspipelines siehe Einschränkungen.

Verwandte Inhalte

  • Last updated on