Αντιμετώπιση προβλημάτων ενοποίησης Git για ανάπτυξη αποθήκης

Ισχύει για: ✅ Αποθήκη στο Microsoft Fabric

Αυτό το άρθρο περιλαμβάνει θέματα αντιμετώπισης προβλημάτων για την ανάπτυξη και την ανάπτυξη Fabric αποθήκη δεδομένων με την ενσωματωμένη ενσωμάτωση Git του Fabric.

Important

Αυτή η δυνατότητα είναι σε προεπισκόπηση.

Αναφορές στα αντικείμενα της ίδιας της αποθήκης με χρήση τριμερούς ονόματος

Ένα αντικείμενο μπορεί να αναφέρεται σε ένα άλλο αντικείμενο στην ίδια αποθήκη χρησιμοποιώντας ένα όνομα τριών μερών, [warehouse_name].[schema_name].[object_name].

Η ονομασία τριών μερών προορίζεται για αναφορά σε διαφορετική αποθήκη. Όταν το τμήμα της βάσης δεδομένων ονομάζει την τρέχουσα αποθήκη, η κατασκευή αντιμετωπίζει την αναφορά ως εξωτερική και το αντικείμενο καταλήγει να ορίζεται δύο φορές στο μοντέλο.

Αφαιρέστε το τμήμα βάσης δεδομένων από αναφορές σε αντικείμενα της αποθήκης:

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

Μόνο οι αναφορές στα αντικείμενα της αποθήκης πρέπει να αλλάξουν. Υποστηρίζονται γνήσιες αναφορές μεταξύ βάσεων δεδομένων σε άλλες αποθήκες, όπως [Other_Warehouse].[Sales].[Orders], και θα πρέπει να παραμείνουν as-is.

Important

Χρησιμοποιήστε την ονομασία τριών τμημάτων (database.schema.object) μόνο για αναφορές τελικών σημείων ανάλυσης μεταξύ αποθηκών ή SQL, όχι για αναφορά αντικειμένων εντός της ίδιας αποθήκης. Η αυτοαναφορά αντικειμένων στην ίδια αποθήκη με τη χρήση τριμερούς ονομασίας δεν αποτελεί τυπική πρακτική μοντελοποίησης και μπορεί να δημιουργήσει ακούσιες εξωτερικές αναφορές.

Όπου είναι δυνατό, μοντελοποιήστε αντικείμενα χρησιμοποιώντας ονομασία δύο τμημάτων (schema.object) αντί για ονομασία τριών μερών, ακόμη και για αυτοαναφορές εντός της ίδιας αποθήκης. Αυτή η σύμβαση βελτιώνει τη συνέπεια μεταξύ των εργαλείων πελάτη και αποφεύγει την ασάφεια που εισάγουν οι αναφορές σε τρία μέρη.

Μη ενημερωμένο .sqlproj στο αποθετήριο Git

Το αποθετήριο Git μπορεί να περιέχει ένα .sqlproj αρχείο που αναφέρεται σε μια παλαιότερη Microsoft.Build.Sql έκδοση SDK. Το παλαιότερο SDK δεν αναγνωρίζει νεότερη σύνταξη Fabric αποθήκη δεδομένων, όπως IDENTITY στήλες και CLUSTER BY.

Αυτό το ζήτημα επηρεάζει τα αποθετήρια των οποίων τα περιεχόμενα δεσμεύτηκαν πριν από τη μετάβαση της αποθήκης στην τρέχουσα μορφή ορισμού. Οι πιο συνηθισμένες καταστάσεις που οδηγούν σε ένα μη ενημερωμένο αρχείο .sqlproj είναι:

Σύνδεση νέου χώρου εργασίας σε υπάρχον χώρο αποθήκευσης. Η αποθήκη δημιουργείται από ό,τι δεσμεύεται εκεί.
Διακλάδωση σε νέο χώρο εργασίας.
Επαναφορά μιας διαγραμμένης αποθήκης από το Git.
Συγχρονισμός από το Git αμέσως μετά τη μετάβαση της αποθήκης στην τρέχουσα μορφή ορισμού, πριν από την εκτέλεση οποιουδήποτε συγχρονισμού προς την άλλη κατεύθυνση.

Οι αποθήκες που δεν μετακινούνται στην τρέχουσα μορφή ορισμού δεν επηρεάζονται, επειδή το παλαιότερο αρχείο έργου δεν χρησιμοποιείται για τη δημιουργία.

Πώς να επιβεβαιώσετε την έκδοση .sqlproj SDK

Ανοίξτε το αρχείο της αποθήκης .sqlproj στο αποθετήριο και ελέγξτε την έκδοση SDK στο XML:

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

Μια έκδοση που βρίσκεται πίσω από την τρέχουσα Microsoft. Η έκδοση πακέτου Build.Sql υποδεικνύει ένα μη ενημερωμένο αρχείο έργου. Για παράδειγμα, εάν η έκδοσή σας ξεκινά με 0.1.. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Microsoft. Εκδόσεις Build.Sql και Templates.

Ενημέρωση έκδοσης .sqlproj SDK επιλογή Α: συγχρονίστε πρώτα την αποθήκη στο Git

Εάν η αποθήκη υπάρχει ήδη στον χώρο εργασίας και είναι υγιής, δεσμευτείτε από τον χώρο εργασίας στο Git πριν από τον συγχρονισμό προς την άλλη κατεύθυνση. Αυτή η ενέργεια αναδημιουργεί το αρχείο έργου με την τρέχουσα έκδοση SDK, μετά την οποία ο συγχρονισμός από το Git λειτουργεί κανονικά.

Αυτή η επιλογή προτιμάται όπου είναι διαθέσιμη, επειδή επικαιροποιεί ολόκληρο τον ορισμό και όχι μόνο το χαρακτηριστικό SDK.

Η αποθήκη πρέπει να είναι ήδη στην τρέχουσα μορφή ορισμού για να λειτουργήσει αυτή η επιλογή. Εάν δεν είναι, αναβαθμίστε το πρώτα στον πίνακα Fabric Git και, στη συνέχεια, δεσμευτείτε στο Git. Η δέσμευση από μια αποθήκη που εξακολουθεί να είναι στην παλαιότερη μορφή ορισμού εγγράφει την παλαιότερη μορφή πίσω στο αποθετήριο και δεν ανανεώνει την έκδοση SDK, επομένως ο επόμενος συγχρονισμός αποτυγχάνει με τον ίδιο τρόπο. Εάν δεν μπορείτε να κάνετε αναβάθμιση, χρησιμοποιήστε την επιλογή επιδιόρθωσης Β .

Ενημέρωση έκδοσης .sqlproj SDK επιλογή Β: ενημερώστε το αρχείο .sqlproj απευθείας στο Git

Χρησιμοποιήστε αυτήν την επιλογή όταν η αποθήκη δεν υπάρχει ακόμα στον χώρο εργασίας προορισμού, όπως όταν συνδέετε έναν νέο χώρο εργασίας σε ένα υπάρχον αποθετήριο, διακλαδώνετε ή επαναφέρετε μια διαγραμμένη αποθήκη. Σε αυτές τις περιπτώσεις, δεν υπάρχει αποθήκη για συγχρονισμό, επομένως η επιλογή επιδιόρθωσης Α δεν είναι διαθέσιμη.

Επεξεργαστείτε το .sqlproj αρχείο στο αποθετήριο για να χρησιμοποιήσετε την πιο πρόσφατη έκδοση της Microsoft. Build.Sql και δεσμεύστε την αλλαγή. Για παράδειγμα:

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

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

Η εκτέλεση μιας εξαγωγής ή μιας διαφοράς από μόνη της δεν ενημερώνει το αρχείο έργου. Το αρχείο ξαναγράφεται μόνο όταν ολοκληρωθεί μια υποβολή από τον χώρο εργασίας στο Git ή όταν το επεξεργαστούμε με μη αυτόματο τρόπο.

Μη προσδιορισμένες στήλες σε αντικείμενα που αναφέρονται σε δύο ή περισσότερους πίνακες σε άλλη αποθήκη

Να παρέχετε και να χρησιμοποιείτε πάντα ψευδώνυμα πίνακα κατά την αναφορά στηλών σε ερωτήματα T-SQL.

Όταν ένα ερώτημα T-SQL αναφέρεται σε δύο ή περισσότερους πίνακες σε μια άλλη αποθήκη, η δομή δεν μπορεί να επικυρώσει μια στήλη που έχει γραφτεί χωρίς ψευδώνυμο πίνακα σε έναν συγκεκριμένο πίνακα. Οι πίνακες δεν χρειάζεται να μοιράζονται ένα όνομα στήλης για να υπάρχει αυτή η ασάφεια. Αυτή η ασάφεια υπάρχει στην έκδοση επικύρωσης.
Αυτή η ασάφεια επηρεάζει τα ερωτήματα T-SQL μέσα σε αντικείμενα που αναφέρονται σε δύο ή περισσότερους πίνακες σε άλλη αποθήκη εντός του ίδιου σώματος δήλωσης.
Αυτή η ασάφεια δεν επηρεάζει τα ερωτήματα T-SQL μέσα σε αντικείμενα που αναφέρονται μόνο σε έναν πίνακα σε μια άλλη αποθήκη, επειδή με μία μόνο πηγή δεν υπάρχει τίποτα που να είναι διφορούμενο μεταξύ τους.
Αυτή η ασάφεια δεν επηρεάζει τα ερωτήματα T-SQL που παραμένουν εξ ολοκλήρου σε μία αποθήκη.

Στο παρακάτω παράδειγμα, το έχει fieldinfoμόνο finame , επομένως η SQL είναι έγκυρη και εκτελείται σωστά στην αποθήκη, αλλά υπάρχει ασάφεια στη δομή επικύρωσης.

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

Προσθέστε ένα ψευδώνυμο πίνακα σε κάθε αναφορά στήλης στο επηρεαζόμενο αντικείμενο:

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

Ασυνεπής χρήση κεφαλαίων ονομάτων σχημάτων

Η αποθήκη σας μπορεί να χρησιμοποιήσει μια ταξινόμηση χωρίς διάκριση πεζών-κεφαλαίων, έτσι sales και Sales είναι το ίδιο σχήμα, αλλά τα σενάρια σας μπορεί να το γράφουν και με τους δύο τρόπους σε διαφορετικά σημεία. Οι βάσεις δεδομένων που δεν κάνουν διάκριση πεζών-κεφαλαίων το αποδέχονταν πάντα αυτό, επομένως η ασυνέπεια είναι συνήθως μακροχρόνια και αβλαβής.

Όταν τα σενάρια σας αναφέρονται σε δύο ή περισσότερα διαφορετικά αντικείμενα στο ίδιο σχήμα μιας άλλης αποθήκης και γράφουν αυτό το σχήμα διαφορετικά σε κάθε αναφορά, η κατασκευή δημιουργεί μια CREATE SCHEMA δήλωση για κάθε ορθογραφία. Αυτό το ζήτημα επηρεάζει μόνο τις αποθήκες που αναφέρονται σε άλλη αποθήκη και χρησιμοποιούν συρραφή χωρίς διάκριση πεζών-κεφαλαίων.

Από προεπιλογή, οι αποθήκες στο Fabric χρησιμοποιούν Latin1_General_100_BIN2_UTF8, μια ταξινόμηση με διάκριση πεζών-κεφαλαίων. Οι αποθήκες με διάκριση πεζών-κεφαλαίων δεν επηρεάζονται. Σε αυτές τις αποθήκες, sales και Sales είναι δύο διαφορετικά σχήματα, είτε το σκοπεύετε είτε όχι.
Μια βάση δεδομένων χωρίς διάκριση πεζών-κεφαλαίων δεν μπορεί να περιέχει και τα δύο sales και Sales. Το αντίγραφο προέρχεται μόνο από τις διαφορετικές ορθογραφίες στο κείμενο SQL.

Ελέγξτε τη συρραφή της αποθήκης και τα ModelCollation καθορισμένα στο .sqlproj αρχείο. Αναζητήστε CI (χωρίς διάκριση πεζών-κεφαλαίων) ή CS (με διάκριση πεζών-κεφαλαίων).

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

Διόρθωση

Για να εντοπίσετε ασυνεπή χρήση κεφαλαίων ονομάτων σχήματος στους ορισμούς αντικειμένων αποθήκης, συγκρίνετε τη χρήση κεφαλαίων του σχήματος που ονομάζεται στο σφάλμα σε όλα τα σενάρια σας. Αναζητήστε δύο αναφορές μεταξύ αποθηκών στο ίδιο σχήμα που διαφέρουν μόνο σε περίπτωση.

Χρησιμοποιήστε μια συνεπή χρήση κεφαλαίων παντού, που ταιριάζει με το πραγματικό όνομα σχήματος στην αναφερόμενη αποθήκη. Για παράδειγμα, χρησιμοποιήστε μόνο Sales ή μόνο 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];

Αντιμετωπίζετε αυτό το πρόβλημα όταν έχετε δύο διαφορετικά αντικείμενα με δύο διαφορετικά κεφαλαία σχήματα. Δύο αναφορές στο ίδιο αντικείμενο με διαφορετική χρήση κεφαλαίων διπλώνονται σωστά και δεν αποτυγχάνουν.

Συρραφή στηλών

Εάν ο όρος μιας στήλης COLLATE καθορίζει ρητά την ίδια συρραφή με την προεπιλεγμένη συρραφή της αποθήκης, η εξαγωγή σχήματος του Fabric (βασισμένη σε DacFx) αντιμετωπίζει τη ρητή συρραφή ως ισοδύναμη με τον μη καθορισμό καθόλου. Σε αυτήν την περίπτωση:

Ο ρητός COLLATE όρος δεν εμφανίζεται στον ορισμό του στοιχείου που εξάγεται στο αποθετήριο Git.
Η στήλη δεν εμφανίζεται ως διαφορά στις αλλαγές Git, τις ενημερώσεις ή τις συγκρίσεις διοχέτευσης ανάπτυξης, επειδή δεν υπάρχει ουσιαστική διαφορά από την προεπιλεγμένη ταξινόμηση της αποθήκης.

Μόνο οι στήλες των οποίων η συρραφή διαφέρει από την προεπιλεγμένη συρραφή της αποθήκης διατηρούν έναν ρητό COLLATE όρο στον έλεγχο προέλευσης και μόνο οι αλλαγές στη συρραφή αυτών των στηλών εμφανίζονται ως διαφορές.

Για παράδειγμα, σκεφτείτε μια αποθήκη της οποίας η ταξινόμηση είναι 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 δεν έχει ρητή συρραφή και κληρονομεί την προεπιλεγμένη συρραφή της αποθήκης.
LastNameBin έχει μια ρητή συρραφή που διαφέρει από την προεπιλεγμένη συρραφή της αποθήκης, επομένως διατηρείται στον ορισμό που έχει εξαχθεί και εμφανίζεται πάντα στις συγκρίσεις εάν αλλάξει.
Email έχει ρητή συρραφή που ταιριάζει με την προεπιλεγμένη συρραφή της αποθήκης. Παρόλο που ο COLLATE όρος υπάρχει στην T-SQL, δεν εμφανίζεται στον ορισμό που εξάγεται από το Git ή στις συγκρίσεις του Git ή της διοχέτευσης ανάπτυξης, επειδή είναι ισοδύναμος με την προεπιλογή.

Διφορούμενα σφάλματα στηλών με διπλότυπα υποψήφια αντικείμενα

Η δέσμευση ή η ενημέρωση από το Git μπορεί να αποτύχει με ένα διφορούμενο σφάλμα στήλης του οποίου η λίστα υποψηφίων περιέχει ένα :: διαχωριστικό, για παράδειγμα:

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

Το :: διαχωριστικό διακρίνει αυτό το σφάλμα από την πραγματική ασάφεια που περιγράφεται στις στήλες Μη προσδιορισμένο σε αντικείμενα που αναφέρονται σε δύο ή περισσότερους πίνακες σε μια άλλη αποθήκη. Η προσθήκη ενός ψευδωνύμου πίνακα δεν επιλύει το πρόβλημα, καθώς το ψευδώνυμο εμφανίζεται στη λίστα υποψηφίων και το σφάλμα εξακολουθεί να εμφανίζεται.

Αρχικά, αποκλείστε αυτές τις δύο πιο κοινές αιτίες:
- Ένα πραγματικά χαμένο ή λάθος όνομα. Εάν η ίδια υποβολή ή ενημέρωση αναφέρει επίσης μια ανεπίλυτη αναφορά σε ένα συγκεκριμένο αντικείμενο που λείπει, όπως SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable]το , διορθώστε πρώτα αυτήν την αναφορά. Οι :: υποψήφιοι συνήθως καθαρίζουν μαζί του.
- Μια πραγματικά διφορούμενη στήλη. Εάν μια μη προσδιορισμένη στήλη έχει επιλεγεί πάνω από μια ένωση δύο προελεύσεων που και οι δύο εκθέτουν μια στήλη με αυτό το όνομα, προσδιορίστε τη στήλη με το ψευδώνυμο του πίνακα, για παράδειγμα a.[NCESID]. Ο SQL Server θα απέρριπτε και αυτό το ερώτημα, επομένως δεν είναι συγκεκριμένο για την ενοποίηση του Git.
Εάν υπάρχει κάθε αντικείμενο αναφοράς και καμία στήλη δεν είναι πραγματικά διφορούμενη, οι :: υποψήφιοι είναι ένα γνωστό ζήτημα στην επικύρωση που εκτελείται κατά τη διάρκεια υποβολών και ενημερώσεων από το Git, που παρακολουθείται από την ομάδα προϊόντων. Δοκιμάστε αυτές τις λύσεις, με τη σειρά:
1. Αντικαταστήστε SELECT * τα CTE και τους παράγωγους πίνακες με μια ρητή λίστα στηλών.
2. Διαιρέστε την προβολή έτσι ώστε κάθε διφορούμενη προέλευση να ορίζεται στη δική της προβολή και αναφέρετε αυτήν την προβολή αντί να επαναλάβετε το υποκείμενο ερώτημα.
3. Αποφύγετε τη σύνδεση OPENROWSET(BULK ...) με άλλη δυναμικά διαμορφωμένη πηγή στην ίδια δήλωση.

Εάν κανένα από αυτά δεν επιλύσει το σφάλμα, συλλέξτε τον ορισμό του αντικειμένου που ονομάζεται στο σφάλμα και ανοίξτε μια αίτηση υποστήριξης. Για περιορισμούς ειδικά για τις διοχετεύσεις ανάπτυξης, ανατρέξτε στην ενότητα Περιορισμοί.

Σχόλια

Ήταν χρήσιμη αυτή η σελίδα;

Last updated on 2026-07-31