Fejlfinding af Git-integration til lagerudvikling

Gælder for: ✅ Lager i Microsoft Fabric

Denne artikel indeholder fejlfinding til udvikling og implementering af Fabric data warehouse med Fabric indbyggede Git-integration.

Vigtigt!

Denne funktion er en prøveversion.

Henvisninger til lagerets egne objekter ved brug af et tredelt navn

Et objekt kan referere til et andet objekt i samme lager ved at bruge et tredelt navn, [warehouse_name].[schema_name].[object_name].

Tre-delt navngivning er beregnet til at referere til et andet lager. Når databasedelen navngiver det aktuelle warehouse, behandler buildet referencen som ekstern, og objektet bliver defineret to gange i modellen.

Fjern databasedelen fra referencer til lagerets egne objekter:

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

Kun referencer til lagerets egne objekter skal ændres. Ægte krydsdatabasereferencer til andre lagre, såsom [Other_Warehouse].[Sales].[Orders], understøttes og bør forblive as-is.

Vigtigt!

Brug kun tre-delt navngivning (database.schema.object) til kryds-warehouse eller tvær-SQL analytics endpoint-referencer, ikke til at referere objekter inden for samme warehouse. Selvrefererende objekter i samme lager ved brug af tre-delt navngivning er ikke en standard modelleringspraksis og kan skabe utilsigtede eksterne referencer.

Hvor det er muligt, modelleres objekter ved at bruge to-delt navngivning (schema.object) i stedet for tre-delt navngivning, selv til selvreferencer inden for samme lager. Denne konvention forbedrer konsistensen på tværs af klientværktøjer og undgår den tvetydighed, som tredelte referencer introducerer.

Forældet .sqlproj i Git-repositoriet

Git-repositoriet kan indeholde en .sqlproj fil, der refererer til en ældre Microsoft.Build.Sql SDK-version. Det ældre SDK genkender ikke nyere Fabric data warehouse syntaks som IDENTITY kolonner og CLUSTER BY.

Dette problem påvirker repositorier, hvis indhold blev committet, før lageret flyttede til det nuværende definitionsformat. De mest almindelige situationer, der resulterer i en forældet .sqlproj-fil, er:

  • At forbinde et nyt arbejdsområde til et eksisterende repository. Lageret skabes ud fra det, der er afleveret der.
  • Udvidelse til et nyt arbejdsområde.
  • Genskaber et slettet lager fra Git.
  • Synkronisering fra Git umiddelbart efter, at lageret er flyttet til det nuværende definitionsformat, før nogen synkronisering i den modsatte retning er kørt.

Lagre, der ikke er flyttet til det nuværende definitionsformat, påvirkes ikke, fordi den ældre projektfil ikke bruges til at bygge.

Sådan bekræfter du .sqlproj SDK-versionen

Åbn lagerets .sqlproj fil i repositoryet og tjek SDK-versionen i XML'en:

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

En version, der er bagud i forhold til det nuværende Microsoft. Build.SQL-pakkeversionen angiver en forældet projektfil. For eksempel, hvis din version starter med 0.1.. For mere information, se Microsoft. Build.SQL og skabelonudgivelser.

Opdater .sqlproj SDK versionsmulighed A: synkroniser warehouse først med Git

Hvis lageret allerede eksisterer i arbejdsområdet og er sundt, så commit fra arbejdsområdet til Git, før du synkroniserer i den modsatte retning. Denne handling gengenererer projektfilen med den aktuelle SDK-version, hvorefter synkronisering fra Git fungerer normalt.

Denne mulighed foretrækkes, hvor det er muligt, fordi den opdaterer hele definitionen i stedet for kun SDK-attributtet.

Lageret skal allerede være på det nuværende definitionsformat for at denne mulighed kan virke. Hvis ikke, opgrader den først i Fabric Git-panelet, og commit derefter til Git. Committing fra et lager, der stadig er på det ældre definitionsformat, skriver det ældre format tilbage til repositoryet og opdaterer ikke SDK-versionen, så næste synkronisering fejler på samme måde. Hvis du ikke kan opgradere, så brug i stedet fix option B .

Opdater .sqlproj SDK version mulighed B: opdater .sqlproj-filen direkte i Git

Brug denne mulighed, når lageret endnu ikke eksisterer i målarbejdsområdet, for eksempel når du forbinder et nyt arbejdsområde til et eksisterende repository, udvider eller gendanner et slettet lager. I de tilfælde er der ikke noget lager at synkronisere fra, så fix option A er ikke tilgængelig.

Rediger .sqlproj filen i repositoryet for at bruge den nyeste Microsoft. Build.SQL-pakkeversionen og commit ændringen. Eksempel: 

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

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

At køre en eksport eller en differential alene opdaterer ikke projektfilen. Filen bliver kun omskrevet, når en commit fra arbejdsområdet til Git er færdig, eller når du redigerer den manuelt.

Ukvalificerede kolonner i objekter, der refererer til to eller flere tabeller i et andet lager

Angiv og brug altid tabelaliaser, når du refererer til kolonner i T-SQL-forespørgsler.

  • Når en T-SQL-forespørgsel refererer til to eller flere tabeller i et andet lager, kan buildet ikke validere en kolonne skrevet uden tabelalias til en specifik tabel. Tabellerne behøver ikke at dele et kolonnenavn for at denne tvetydighed kan eksistere. Denne tvetydighed findes i valideringsopbygningen.
  • Denne tvetydighed påvirker T-SQL-forespørgsler inde i objekter, der refererer til to eller flere tabeller i et andet warehouse inden for samme sætningskrop.
  • Denne tvetydighed påvirker ikke T-SQL-forespørgsler i objekter, der kun refererer til én tabel i et andet warehouse, fordi der med en enkelt kilde ikke er noget at være tvetydig imellem.
  • Denne tvetydighed påvirker ikke T-SQL-forespørgsler, der forbliver helt inden for ét lager.

I det følgende eksempel har fieldinfokun finame , så SQL er gyldig og kører korrekt mod warehouse, men der findes tvetydighed i valideringsbuildet.

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

Tilføj et tabelalias til hver kolonnereference i det berørte objekt:

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

Inkonsistent brug af store bogstaver i skemanavne

Dit lager kan bruge en kasus-insensitive sammenstilling, så sales og Sales er det samme skema, men dine scripts kan stave det begge veje forskellige steder. Databaser uden store sager har altid accepteret det, så inkonsistensen er som regel langvarig og harmløs.

Når dine scripts refererer til to eller flere forskellige objekter i det samme skema i et andet lager og staver det skema forskelligt i hver reference, genererer buildet en CREATE SCHEMA sætning for hver stavning. Dette problem gælder kun lagre, der refererer til et andet lager og bruger en kasus-ufølsom sammenstilling.

  • Som standard bruger Latin1_General_100_BIN2_UTF8lagre i Fabric , en case-sensitiv sortering. Case-sensitive lagre påvirkes ikke. I disse lagre er der sales to forskellige skemaer, Sales uanset om du har det til hensigt eller ej.
  • En database uden store og små bogstaver kan ikke indeholde både sales og Sales. Duplikaten kommer kun fra de forskellige stavemåder i din SQL-tekst.

Tjek lagerets samling og det, der ModelCollation er angivet i filen .sqlproj . Se efter CI (kasus-følsom) eller CS (småbogstav-følsom).

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

Ret

For at identificere inkonsistent skemanavn-kapitalisering i dine warehouse-objektdefinitioner, sammenlign kapitaliseringen af det skema, der er nævnt i fejlen, på tværs af alle dine scripts. Se efter to tværlagerreferencer til det samme skema, som kun adskiller sig i tilfælde.

Brug én ensartet stor bogstav overalt, der matcher det faktiske skemanavn i det refererede lager. For eksempel kun eller kun Salessales.

-- 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øder på dette problem, når du har to forskellige objekter med to forskellige skema-bogstaver. To referencer til det samme objekt med forskellig bogstav foldes korrekt og fejler ikke.

Kolonne-kollation

Hvis en kolonnes COLLATE klausul eksplicit specificerer den samme kollation som lagerets standardkollation, behandler Fabric's skema-ekstraktion (DacFx-baseret) den eksplicitte kollation som ækvivalent med slet ikke at specificere en. I dette tilfælde:

  • Den eksplicitte COLLATE klausul optræder ikke i den item-definition, der er udtrukket til Git-repositoryet.
  • Kolonnen vises ikke som en forskel i Git-ændringer, opdateringer eller sammenligninger af deployment pipelines, fordi der ikke er nogen effektiv forskel fra warehouse's standard-samling.

Kun kolonner, hvis kollation adskiller sig fra lagerets standardkollation, bevarer en eksplicit COLLATE klausul i versionskontrol, og kun ændringer i disse kolonners kollation vises som forskelle.

For eksempel, betragt et lager, hvis kollation er 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 eksplicit kollation og arver lagerets standardkollation.
  • LastNameBin har en eksplicit kollation, der adskiller sig fra lagerets standard-kollation, så den bevares i den udtrukne definition og altid vises i sammenligninger, hvis den ændres.
  • Email har en eksplicit kollation, der matcher lagerets standardkollation. Selvom COLLATE klausulen er til stede i T-SQL, optræder den ikke i Git-udpakkede definition eller i Git- eller deployment-pipeline-sammenligninger, fordi den svarer til standarden.

Tvetydige kolonnefejl med duplikerede kandidatobjekter

Committing eller opdatering fra Git kan fejle med en tvetydig kolonnefejl, hvis kandidatliste indeholder en :: separator, for eksempel:

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

Separatoren :: adskiller denne fejl fra den ægte tvetydighed, der beskrives i Ukvalificerede kolonner i objekter, der refererer til to eller flere tabeller i et andet lager. At tilføje et tabelalias løser det ikke, da aliaset vises i kandidatlisten, og fejlen opstår stadig.

  1. For det første, udeluk disse to mere almindelige årsager:

    • Et ægte manglende eller fejlagtigt navngivet objekt. Hvis den samme commit eller opdatering også rapporterer en uløst reference til et specifikt manglende objekt, såsom SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable], ret den reference først. Kandidaterne :: klarer som regel sammen med det.
    • En ægte tvetydig klumme. Hvis en ukvalificeret kolonne vælges over en sammenslutning af to kilder, der begge eksponerer en kolonne med det navn, kvalificeres kolonnen med dens tabelalias, for eksempel a.[NCESID]. SQL Server vil også afvise denne forespørgsel, så den er ikke specifik for Git-integration.

  2. Hvis alle refererede objekter eksisterer, og ingen kolonne er ægte tvetydig, er kandidaterne :: et kendt problem i valideringen, der kører under commits og opdateringer fra Git og spores af produktteamet. Prøv disse løsninger, i rækkefølge:

    1. Erstat SELECT * interne CTE'er og afledte tabeller med en eksplicit kolonneliste.
    2. Del visningen, så hver tvedig kilde defineres i sin egen visning, og referer til den visning i stedet for at gentage den underliggende forespørgsel.
    3. Undgå at koble til OPENROWSET(BULK ...) en anden dynamisk formet kilde i samme udsagn.

Hvis ingen af disse løser fejlen, indsaml definitionen af objektet i fejlen og åbn en supportanmodning. For begrænsninger, der er specifikke for deployment-pipelines, se Begrænsninger.

Relateret indhold

  • Last updated on