Felsök Git-integration för lagerutveckling

Gäller för: ✅ Warehouse i Microsoft Fabric

Den här artikeln innehåller felsökningsämnen för utveckling och implementering av Fabric Data Warehouse med Fabric inbyggda Git-integration.

Referenser till lagrets egna objekt genom att använda ett tredelat namn

Ett objekt kan referera till ett annat objekt i samma lager genom att använda ett tredelat namn, [warehouse_name].[schema_name].[object_name].

Tredelad namngivning är avsedd för att referera till ett annat lager. När databasdelen namnger det aktuella lagret behandlar bygget referensen som extern, och objektet definieras två gånger i modellen.

Ta bort databasdelen från referenser till lagrets egna objekt:

-- 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;

Endast referenser till lagrets egna objekt behöver ändras. Äkta korsdatabasreferenser till andra lager, såsom [Other_Warehouse].[Sales].[Orders], stöds och bör förbli as-is.

Föråldrad .sqlproj i Git-arkivet

Git-arkivet kan innehålla en .sqlproj fil som refererar till en äldre Microsoft.Build.Sql SDK-version. Den äldre SDK:n känner inte igen nyare Fabric Data Warehouse syntax som IDENTITY kolumner och CLUSTER BY.

Detta problem påverkar arkiv vars innehåll sattes in innan lagret gick över till det nuvarande definitionsformatet. De vanligaste situationerna som leder till en inaktuell .sqlproj-fil är:

• Koppla en ny arbetsyta till ett befintligt arkiv. Lageret skapas av det som är avslutat där.
• Att bredda sig till en ny arbetsplats.
• Återställer ett raderat lager från Git.
• Synkronisering från Git omedelbart efter att lagret flyttat till det aktuella definitionsformatet, innan någon synkronisering i motsatt riktning har körts.

Lager som inte flyttas till det nuvarande definitionsformatet påverkas inte, eftersom den äldre projektfilen inte används för att bygga.

Hur man bekräftar .sqlproj SDK-versionen

Öppna lagrets .sqlproj fil i arkivet och kontrollera SDK-versionen i XML:en:

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

En version som ligger efter nuvarande Microsoft. Build.SQL-paketversionen indikerar en föråldrad projektfil. Till exempel, om din version börjar med 0.1.. För mer information, se Microsoft. Build.SQL och mallutgåvor.

Uppdatera .sqlproj SDK versionsalternativ A: synkronisera lagret till Git först

Om lagret redan finns i arbetsytan och är friskt, committa från arbetsytan till Git innan du synkar åt andra hållet. Denna åtgärd regenererar projektfilen med den aktuella SDK-versionen, varefter synkroniseringen från Git fungerar normalt.

Detta alternativ föredras där det är möjligt, eftersom det uppdaterar hela definitionen istället för bara SDK-attributet.

Lageret måste redan ha det aktuella definitionsformatet för att detta alternativ ska fungera. Om det inte är det, uppgradera det först i Fabric Git-panelen och commit sedan till Git. Att committa från ett lager som fortfarande är på det äldre definitionsformatet skriver tillbaka det äldre formatet till repositoryt och uppdaterar inte SDK-versionen, så nästa synkronisering misslyckas på samma sätt. Om du inte kan uppgradera, använd istället fixalternativ B .

Uppdatera .sqlproj SDK version alternativ B: uppdatera .sqlproj-filen direkt i Git

Använd detta alternativ när lagret ännu inte finns i målarbetsytan, till exempel när du kopplar en ny arbetsyta till ett befintligt arkiv, expanderar eller återställer ett raderat lager. I de fallen finns det inget lager att synka från, så fixalternativ A finns inte tillgängligt.

Redigera .sqlproj filen i arkivet för att använda den senaste Microsoft. Build.SQL-paketversionen och committa ändringen. Ett exempel:

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

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

Att köra en export eller en diff i sig uppdaterar inte projektfilen. Filen skrivs bara om när en commit från arbetsområdet till Git är klar, eller när du redigerar den manuellt.

Okvalificerade kolumner i objekt som refererar till två eller fler tabeller i ett annat lager

Ange och använd alltid tabellaliaser när du refererar till kolumner i T-SQL-frågor.

• När en T-SQL-fråga refererar till två eller fler tabeller i ett annat lager kan bygget inte validera en kolumn skriven utan tabellalias till en specifik tabell. Tabellerna behöver inte dela kolumnnamn för att denna tvetydighet ska existera. Denna tvetydighet finns i valideringsbygget.
• Denna tvetydighet påverkar T-SQL-frågor i objekt som refererar till två eller fler tabeller i ett annat lager inom samma satskropp.
• Denna tvetydighet påverkar inte T-SQL-frågor i objekt som bara refererar till en tabell i ett annat lager, eftersom det inte finns något att vara tvetydig mellan med en enda källa.
• Denna oklarhet påverkar inte T-SQL-frågor som förblir helt inom ett och samma lager.

I följande exempel har fieldinfoendast finame , så SQL är giltigt och körs korrekt mot lagret, men det finns tvetydighet i valideringsbygget.

-- 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];

Lägg till ett tabellalias till varje kolumnreferens i det berörda objektet:

-- 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];

Inkonsekvent versaler i schemanamn

Ditt lager kan använda en kasus-okänslig kollation, så sales och Sales är samma schema, men dina skript kan stava det på båda sätten på olika ställen. Databaser med inkänslighet för små och små steg har alltid accepterat det, så inkonsekvensen är oftast långvarig och harmlös.

När dina skript refererar till två eller fler olika objekt i samma schema i ett annat lager och stavar det schemat olika i varje referens, genererar bygget ett CREATE SCHEMA uttalande för varje stavning. Detta problem gäller endast lager som refererar till ett annat lager och använder en kasus-okänslig sammanställning.

• Som standard använder Latin1_General_100_BIN2_UTF8lager i Fabric , en kasuskänslig sortering. Fallkänsliga lager påverkas inte. I dessa lager sales finns det Sales två olika scheman, oavsett om du tänker det eller inte.
• En kasuskänslig databas kan inte innehålla både sales och Sales. Dubbletten kommer bara från de olika stavningarna i din SQL-text.

Kontrollera lagersorteringen och vad som ModelCollation anges i .sqlproj filen. Sök efter CI (kasuskänslig) eller CS (kasuskänslig).

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

Reparera

För att identifiera inkonsekvent schemanamnsanvändning i dina lagerobjektdefinitioner, jämför versalern i schemat som nämns i felet mellan alla dina skript. Leta efter två korslagerreferenser till samma schema som skiljer sig endast i fall.

Använd en konsekvent versaler överallt, som matchar det faktiska schemanamnet i det refererade lagret. Till exempel, använd endast Sales eller endast 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];

Du stöter på detta problem när du har två olika objekt med två olika schema-versaler. Två referenser till samma objekt med olika versaler viks korrekt och misslyckas inte.

Kolumnkollation

Om en kolumns COLLATE klausul uttryckligen specificerar samma kollation som lagrets standardkollation, behandlar Fabric:s schemaextraktion (DacFx-baserad) den explicita kollationen som likvärdig med att inte specificera någon alls. I det här fallet:

• Den explicita COLLATE klausulen förekommer inte i artikeldefinitionen som extraheras till Git-arkivet.
• Kolumnen visas inte som en skillnad i Git-ändringar, uppdateringar eller jämförelser av distributionspipelines, eftersom det inte finns någon effektiv skillnad från lagrets standardsortering.

Endast kolumner vars kollation skiljer sig från lagrets standardkollation behåller en explicit COLLATE klausul i källkontrollen, och endast ändringar i dessa kolumners sortering visas som skillnader.

Till exempel, betrakta ett lager vars sortering är 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 har ingen explicit kollation och ärver lagrets standardkollation.
• LastNameBin har en explicit kollation som skiljer sig från lagrets standardsortering, så den bevaras i den extraherade definitionen och syns alltid i jämförelser om den ändras.
• Email har en explicit kollation som matchar lagerets standardkollation. Även om COLLATE klausulen finns i T-SQL, förekommer den inte i Git-extraherad definition eller i Git- eller distributionspipeline-jämförelser, eftersom den är ekvivalent med standarden.

Tvetydiga kolumnfel med dubbletter av kandidatobjekt

Att committa eller uppdatera från Git kan misslyckas med ett tvetydigt kolumnfel vars kandidatlista innehåller en :: separator, till exempel:

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].

Separatorn :: skiljer detta fel från den genuina tvetydigheten som beskrivs i Icke-kvalificerade kolumner i objekt som refererar till två eller fler tabeller i ett annat lager. Att lägga till ett tabellalias löser det inte eftersom aliaset visas i kandidatlistan och felet fortfarande uppstår.

1. För det första, uteslut dessa två vanligaste orsaker:

   • Ett genuint saknat eller felnamngivet föremål. Om samma commit eller uppdatering också rapporterar en olöst referens till ett specifikt saknat objekt, såsom SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable], fixa den referensen först. Kandidaterna :: brukar gå igenom det.
   • En genuint tvetydig kolumn. Om en okvalificerad kolumn väljs över en sammanfogning av två källor som båda visar en kolumn med det namnet, kvalificera kolumnen med dess tabellalias, till exempel a.[NCESID]. SQL Server skulle också avvisa denna fråga, så det är inte specifikt för Git-integration.

2. Om varje refererat objekt finns och ingen kolumn är genuint tvetydig, är kandidaterna :: ett känt problem i valideringen som körs under commits och uppdateringar från Git, spårad av produktteamet. Prova dessa lösningar, i ordning:

   1. Ersätt SELECT * inuti CTE:er och härledda tabeller med en explicit kolumnlista.
   2. Dela upp vyn så att varje tvetydig källa definieras i sin egen vy, och referera till den vyn istället för att upprepa den underliggande frågan.
   3. Undvik att ansluta OPENROWSET(BULK ...) till en annan dynamiskt formad källa i samma uttalande.

Om inget av dessa löser felet, samla in definitionen av objektet som nämns i felet och öppna en supportförfrågan. För begränsningar specifika för distributionspipelines, se Begränsningar.

Relaterat innehåll

• Kom igång med Git-integrering
• Använd Git Integration för lagerutveckling och distribution