Feilsøk Git-integrasjon for lagerutvikling

Gjelder for: ✅ Warehouse i Microsoft Fabric

Denne artikkelen inkluderer feilsøkingstemaer for utvikling og distribusjon av Fabric datalager med Fabric innebygde Git-integrasjon.

Referanser til lagerets egne objekter ved bruk av et tredelt navn

Et objekt kan referere til et annet objekt i samme lager ved å bruke et tredelt navn, [warehouse_name].[schema_name].[object_name].

Tredelt navngivning er ment for å referere til et annet lager. Når databasedelen navngir det nåværende lageret, behandler bygget referansen som ekstern, og objektet blir definert to ganger i modellen.

Fjern databasedelen fra referanser 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 referanser til lagerets egne objekter må endres. Ekte kryssdatabasereferanser til andre lagre, som [Other_Warehouse].[Sales].[Orders], støttes og bør forbli as-is.

Utdatert .sqlproj i Git-repositoriet

Git-repositoriet kan inneholde en .sqlproj fil som refererer til en eldre Microsoft.Build.Sql SDK-versjon. Den eldre SDK-en gjenkjenner ikke nyere Fabric datalager syntaks som IDENTITY kolonner og CLUSTER BY.

Dette problemet gjelder repositorier hvis innhold ble inngått før lageret gikk over til dagens definisjonsformat. De vanligste situasjonene som resulterer i en utdatert .sqlproj-fil er:

• Koble et nytt arbeidsområde til et eksisterende arkiv. Lageret er laget av det som er forpliktet der.
• Å utvide til et nytt arbeidsområde.
• Gjenoppretter et slettet lager fra Git.
• Synkronisering fra Git umiddelbart etter at lageret har flyttet til det nåværende definisjonsformatet, før noen synkronisering i motsatt retning har kjørt.

Lagre som ikke flyttes til dagens definisjonsformat påvirkes ikke, fordi den eldre prosjektfilen ikke brukes til å bygge.

Hvordan bekrefte .sqlproj SDK-versjonen

Åpne lagerets .sqlproj fil i repositoriet og sjekk SDK-versjonen i XML-en:

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

En versjon som ligger bak dagens Microsoft. Build.SQL-pakkeversjonen indikerer en utdatert prosjektfil. For eksempel, hvis versjonen din starter med 0.1.. For mer informasjon, se Microsoft. Build.SQL og malutgivelser.

Oppdater .sqlproj SDK versjonsalternativ A: synkroniser warehouse til Git først

Hvis lageret allerede eksisterer i arbeidsområdet og er friskt, committer du fra arbeidsområdet til Git før du synkroniserer i motsatt retning. Denne handlingen genererer prosjektfilen med gjeldende SDK-versjon, hvoretter synkronisering fra Git fungerer normalt.

Dette alternativet foretrekkes der det er tilgjengelig, fordi det oppdaterer hele definisjonen i stedet for bare SDK-attributtet.

Lageret må allerede være på det nåværende definisjonsformatet for at dette alternativet skal fungere. Hvis det ikke er det, oppgrader det først i Fabric Git-panelet, og forplikt deg deretter til Git. Å committe fra et lager som fortsatt er på det eldre definisjonsformatet skriver det eldre formatet tilbake til repositoryet og oppdaterer ikke SDK-versjonen, så neste synkronisering feiler på samme måte. Hvis du ikke kan oppgradere, bruk fiks alternativ B i stedet.

Oppdater .sqlproj SDK versjon alternativ B: oppdater .sqlproj-filen direkte i Git

Bruk dette alternativet når lageret ennå ikke eksisterer i målarbeidsområdet, for eksempel når du kobler et nytt arbeidsområde til et eksisterende lager, utvider eller gjenoppretter et slettet lager. I slike tilfeller finnes det ikke noe lager å synkronisere fra, så fiksealternativ A er ikke tilgjengelig.

Rediger .sqlproj filen i repositoriet for å bruke den nyeste Microsoft. Build.SQL-pakkeversjon og commit endringen. Eksempel:

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

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

Å kjøre en eksport eller en differensial alene oppdaterer ikke prosjektfilen. Filen skrives bare om når en commit fra arbeidsområdet til Git er fullført, eller når du redigerer den manuelt.

Ukvalifiserte kolonner i objekter som refererer til to eller flere tabeller i et annet lager

Oppgi og bruk alltid tabellaliaser når du refererer til kolonner i T-SQL-spørringer.

• Når en T-SQL-spørring refererer til to eller flere tabeller i et annet lager, kan ikke bygget validere en kolonne skrevet uten tabellalias til en spesifikk tabell. Tabellene trenger ikke å dele kolonnenavn for at denne tvetydigheten skal eksistere. Denne tvetydigheten finnes i valideringsbygget.
• Denne tvetydigheten påvirker T-SQL-spørringer inne i objekter som refererer til to eller flere tabeller i et annet lager innenfor samme setningskropp.
• Denne tvetydigheten påvirker ikke T-SQL-spørringer inne i objekter som kun refererer til én tabell i et annet lager, fordi med én enkelt kilde er det ingenting å være tvetydig mellom.
• Denne tvetydigheten påvirker ikke T-SQL-spørringer som holder seg helt innenfor ett lager.

I det følgende eksempelet har fieldinfokun finame , så SQL er gyldig og kjører korrekt mot lageret, men det finnes 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];

Legg til et tabellalias til hver kolonnereferanse i det berørte 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];

Inkonsistent bruk av store bokstaver i skjemanavn

Lageret ditt kan bruke en kasus-insensitiv kollasjon, så sales og Sales er samme skjema, men skriptene dine kan stave det begge veier på forskjellige steder. Databaser med ufølsomt innhold har alltid akseptert dette, så inkonsistensen er vanligvis langvarig og ufarlig.

Når skriptene dine refererer til to eller flere forskjellige objekter i samme skjema i et annet lager, og staver det skjemaet forskjellig i hver referanse, genererer bygget en CREATE SCHEMA setning for hver stavemåte. Dette problemet gjelder kun lagre som refererer til et annet lager og bruker en case-insensitive sammenstilling.

• Som standard bruker Latin1_General_100_BIN2_UTF8lagre i Fabric , en kasussensitiv sortering. Case-sensitive lagre blir ikke berørt. I disse lagrene sales finnes det Sales to forskjellige skjemaer, enten du mener det eller ikke.
• En database uten små og små bokstaver kan ikke inneholde både sales og Sales. Duplikaten kommer kun fra de ulike stavemåtene i SQL-teksten din.

Sjekk lagerets sammensetning og det ModelCollation som er spesifisert i filen .sqlproj . Se etter CI (kasus-sensitiv) eller CS (kasus-sensitiv).

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

Rett

For å identifisere inkonsistente store bokstaver i store bokstaver i lagerets objektdefinisjoner, sammenlign store bokstaver i skjemaet som er nevnt i feilen på tvers av alle skriptene dine. Se etter to tverrlagerreferanser til samme skjema som kun skiller seg i tilfelle.

Bruk én konsekvent stor bokstav overalt, som matcher det faktiske skjemanavnet i det refererte lageret. For eksempel, bruk kun Sales eller kun 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å dette problemet når du har to forskjellige objekter med to forskjellige skjema-store bokstaver. To referanser til samme objekt med ulik stor bokstav er korrekt brettet og feiler ikke.

Kolonne-sortering

Hvis en kolonnes COLLATE klausul eksplisitt spesifiserer samme kollasjon som lagerets standardkollasjon, behandler Fabric sin skjema-ekstraksjon (DacFx-basert) den eksplisitte kollasjonen som ekvivalent med å ikke spesifisere en i det hele tatt. I dette tilfellet:

• Den eksplisitte COLLATE klausulen vises ikke i varedefinisjonen som hentes ut i Git-repositoriet.
• Kolonnen vises ikke som en forskjell i Git-endringer, oppdateringer eller sammenligninger av distribusjonspipeline, fordi det ikke er noen effektiv forskjell fra lagerets standardsortering.

Kun kolonner hvis kollasjon avviker fra lagerets standardkollasjon beholder en eksplisitt COLLATE klausul i kildekontrollen, og kun endringer i kolonnenes sortering vises som forskjeller.

For eksempel, betrakt et lager hvis kollasjon 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 eksplisitt kollasjon og arver lagerets standardkollasjon.
• LastNameBin har en eksplisitt sortering som avviker fra lagerets standardsortering, så den bevares i den uttrukne definisjonen og vises alltid i sammenligninger hvis den endres.
• Email har en eksplisitt kollasjon som matcher lagerets standardkollasjon. Selv om COLLATE klausulen er til stede i T-SQL, vises den ikke i Git-extracted definisjonen eller i Git- eller distribusjonspipeline-sammenligninger, fordi den tilsvarer standarden.

Tvetydige kolonnefeil med dupliserte kandidatobjekter

Committing eller oppdatering fra Git kan feile med en tvetydig kolonnefeil hvis kandidatliste inneholder 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 :: skiller denne feilen fra den genuine tvetydigheten beskrevet i Ukvalifiserte kolonner i objekter som refererer til to eller flere tabeller i et annet lager. Å legge til et tabellalias løser det ikke, siden aliaset vises i kandidatlisten, og feilen oppstår fortsatt.

1. For det første, utelukk disse to mer vanlige årsakene:

   • Et genuint savnet eller feilnavngitt objekt. Hvis samme commit eller oppdatering også rapporterer en uløst referanse til et spesifikt manglende objekt, for eksempel SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable], fiks den referansen først. Kandidatene :: klarer vanligvis sammen med den.
   • En genuint tvetydig spalte. Hvis en ukvalifisert kolonne velges over en sammenføyning av to kilder som begge eksponerer en kolonne med det navnet, kvalifiserer kolonnen med dens tabellalias, for eksempel a.[NCESID]. SQL Server vil også avvise denne forespørselen, så den er ikke spesifikk for Git-integrasjon.

2. Hvis alle refererte objekter eksisterer og ingen kolonne er genuint tvetydig, er kandidatene :: et kjent problem i valideringen som kjøres under commits og oppdateringer fra Git, sporet av produktteamet. Prøv disse løsningene, i rekkefølge:

   1. Erstatt SELECT * interne CTE-er og avledede tabeller med en eksplisitt kolonneliste.
   2. Del visningen slik at hver tvetydig kilde defineres i sin egen visning, og referer til den visningen i stedet for å gjenta den underliggende forespørselen.
   3. Unngå å koble OPENROWSET(BULK ...) til en annen dynamisk formet kilde i samme utsagn.

Hvis ingen av disse løser feilen, samle definisjonen av objektet som er nevnt i feilen og åpne en supportforespørsel. For begrensninger spesifikke for distribusjonspipelines, se Begrensninger.

Relatert innhold

• Kom i gang med Git-integrasjon
• Bruk Git-integrasjon for lagerutvikling og distribusjon