แก้ไขปัญหาการผสานรวม 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ไฟล์ที่อ้างอิงถึงเวอร์ชัน SDK เก่าMicrosoft.Build.Sql 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 Releases

ตัวเลือกเวอร์ชันอัปเดต .sqlproj SDK A: ซิงค์คลังข้อมูลไปยัง Git ก่อน

ถ้าคลังข้อมูลมีอยู่ใน workspace แล้วและยังสมบูรณ์ ให้ commit จาก workspace ไปยัง Git ก่อนซิงค์ไปอีกทางหนึ่ง การดําเนินการนี้จะสร้างไฟล์โปรเจกต์ใหม่ด้วยเวอร์ชัน SDK ปัจจุบัน หลังจากนั้นการซิงค์จาก Git จะทํางานได้ตามปกติ

ตัวเลือกนี้เป็นที่นิยมหากมี เพราะจะทําให้คํานิยามทั้งหมดทันสมัยขึ้น ไม่ใช่แค่แอตทริบิวต์ SDK เท่านั้น

คลังสินค้าต้องอยู่ในรูปแบบคําจํากัดความปัจจุบันอยู่แล้วเพื่อให้ตัวเลือกนี้ทํางานได้ ถ้าไม่เป็น ให้อัปเกรดก่อนในแผง Fabric Git แล้วค่อยตัดสินใจใช้ Git การ commit จากคลังข้อมูลที่ยังใช้รูปแบบ definition เก่าจะเขียนไฟล์เก่ากลับไปยัง repository และไม่รีเฟรชเวอร์ชัน SDK ดังนั้นการซิงค์ครั้งถัดไปจึงล้มเหลวในลักษณะเดียวกัน ถ้าอัปเกรดไม่ได้ ให้ใช้ วิธีแก้ไข B แทน

ตัวเลือก B อัปเดตเวอร์ชัน .sqlproj SDK: อัปเดตไฟล์ .sqlproj ใน Git โดยตรง

ใช้ตัวเลือกนี้เมื่อคลังสินค้ายังไม่มีอยู่ในพื้นที่ทํางานเป้าหมาย เช่น เมื่อคุณกําลังเชื่อมต่อพื้นที่ทํางานใหม่กับที่เก็บข้อมูลที่มีอยู่ การขยายสาขา หรือการกู้คืนคลังสินค้าที่ถูกลบ ในกรณีเหล่านั้น จะไม่มีคลังสินค้าให้ซิงค์ ดังนั้นตัวเลือกแก้ไข A จึงไม่สามารถใช้งานได้

แก้ไข.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" />

การส่งออกหรือดิฟฟิฟต์เพียงอย่างเดียวจะไม่อัปเดตไฟล์โปรเจกต์ ไฟล์จะถูกเขียนใหม่ก็ต่อเมื่อการ commit จาก workspace ไปยัง Git เสร็จสมบูรณ์ หรือเมื่อคุณแก้ไขด้วยตนเอง

คอลัมน์ที่ไม่ผ่านคุณสมบัติในวัตถุที่อ้างอิงสองตารางขึ้นไปในคลังสินค้าอื่น

ควรให้และใช้ชื่อแทนตารางเสมอเมื่ออ้างอิงคอลัมน์ในคําสั่ง T-SQL

• เมื่อคําสั่ง T-SQL อ้างอิงสองตารางขึ้นไปในคลังข้อมูลอื่น build จะไม่สามารถตรวจสอบความถูกต้องของคอลัมน์ที่เขียนโดยไม่มีชื่อแทนตารางไปยังตารางเฉพาะได้ ตารางไม่จําเป็นต้องมีชื่อคอลัมน์ร่วมกันเพื่อให้เกิดความคลุมเครือนี้ ความคลุมเครือนี้มีอยู่ในบิลด์การตรวจสอบ
• ความคลุมเครือนี้ส่งผลต่อคําสั่ง 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 Schema คือสองรูปแบบที่แตกต่างกัน ไม่ว่าคุณจะตั้งใจหรือไม่ก็ตาม
• ฐานข้อมูลที่ไม่สนใจตัวพิมพ์เล็ก-เล็กไม่สามารถมีทั้ง sales และSales การซ้ํากันเกิดจากการสะกดคําที่แตกต่างกันในข้อความ SQL ของคุณเท่านั้น

ตรวจสอบการจัด เรียงคลังสินค้า และข้อมูล ModelCollation ที่ระบุใน .sqlproj ไฟล์ ค้นหา CI (ไม่สนใจตัวพิมพ์ใหญ่-เล็ก) หรือ CS (ไม่สนใจตัวพิมพ์ใหญ่-เล็ก)

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

Fix

เพื่อระบุการพิมพ์ใหญ่ชื่อสคีมาในนิยามอ็อบเจ็กต์คลังสินค้าของคุณ ให้เปรียบเทียบการพิมพ์ใหญ่ของสคีมาที่ระบุในข้อผิดพลาดในทุกสคริปต์ของคุณ มองหาการอ้างอิงข้ามคลังสินค้าสองรายการที่อ้างอิงโครงสร้างเดียวกันซึ่งแตกต่างกันเฉพาะในกรณีที่มี

ใช้ตัวพิมพ์ใหญ่เดียวที่สอดคล้องกันทุกที่ โดยตรงกับชื่อสคีมาจริงในคลังข้อมูลที่อ้างอิง ตัวอย่างเช่น ใช้ only Sales หรือ only 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];

คุณจะเจอปัญหานี้เมื่อคุณมีวัตถุสองตัวที่แตกต่างกันโดยใช้ตัวพิมพ์ใหญ่ในสคีมาสองแบบ การอ้างอิงถึงวัตถุ เดียวกัน สองครั้งที่มีตัวพิมพ์ใหญ่ต่างกันจะถูกพับให้ถูกต้องและไม่ล้มเหลว

การจัดเรียงคอลัมน์

หาก clause ของCOLLATEคอลัมน์ระบุ collation เดียวกับ collation เริ่มต้นของ warehouse การสกัด schema ของ Fabric (ที่ใช้ DacFx) จะถือว่า collation แบบชัดเจนนั้นเท่ากับไม่ระบุเลย ในกรณีนี้:

• clause explicit COLLATE จะไม่ปรากฏในคํานิยามรายการที่ดึงออกจาก Git repository
• คอลัมน์นี้จะไม่แสดงเป็นความแตกต่างใน Git Changes, Updates หรือการเปรียบเทียบ deployment pipeline เพราะไม่มีความแตกต่างที่มีประสิทธิภาพจากการรวบรวมข้อมูลเริ่มต้นของ warehouse

เฉพาะคอลัมน์ที่การจัดเรียงแตกต่างจากการจัดเรียงเริ่มต้นของคลังเก็บเท่านั้นที่จะ COLLATE ยังคงมี clause ชัดเจนในซอร์สคอนโทรล และการเปลี่ยนแปลงการจัดเรียงของคอลัมน์นั้นจะปรากฏเป็นความแตกต่างเท่านั้น

ตัวอย่างเช่น พิจารณาคลังสินค้าที่มีการจัดเรียงเป็น 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 มีการเรียงลําดับแบบชัดเจนที่ตรงกับการรวบรวมเริ่มต้นของคลังสินค้า แม้ว่า clause จะมี COLLATE ใน T-SQL แต่จะไม่ปรากฏในคําจํากัดความที่ Git ดึงออกมา หรือในการเปรียบเทียบ Git หรือ deployment pipeline เพราะมันเทียบเท่ากับค่าเริ่มต้น

ข้อผิดพลาดคอลัมน์ที่คลุมเครือเมื่อมีวัตถุผู้สมัครซ้ํากัน

การคอมมิตหรืออัปเดตจาก 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].

::ตัวคั่นนี้แยกความแตกต่างนี้ออกจากความกํากวมที่แท้จริงที่อธิบายไว้ในคอลัมน์ Unqualified ในวัตถุที่อ้างอิงตารางสองตารางขึ้นไปในคลังสินค้าอื่น การเพิ่มนามแฝงในตารางไม่สามารถแก้ไขได้ เพราะนามแฝงจะปรากฏในรายการผู้สมัครและข้อผิดพลาดยังคงเกิดขึ้น

1. อันดับแรก ตัดสาเหตุที่พบบ่อยสองประการนี้ออกไป:

   • วัตถุที่หายไปจริง ๆ หรือถูกตั้งชื่อผิด ถ้าคอมมิตหรืออัปเดตเดียวกันยังรายงานการอ้างอิงที่ยังไม่ได้แก้ไขไปยังวัตถุที่หายไปเฉพาะ เช่น SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable]ให้แก้ไขการอ้างอิงนั้นก่อน ::ผู้สมัครมักจะผ่านไปพร้อมกับมัน
   • คอลัมน์ที่คลุมเครือจริง ๆ หากเลือกคอลัมน์ที่ไม่มีคุณสมบัติบนการรวมของแหล่งข้อมูลสองแหล่งที่ทั้งสองเปิดเผยคอลัมน์ที่มีชื่อเดียวกัน ให้ระบุคอลัมน์นั้นด้วยชื่อเล่นในตาราง เช่น a.[NCESID]. SQL Server ก็จะปฏิเสธคําถามนี้เช่นกัน ดังนั้นมันไม่ได้จํากัดเฉพาะการเชื่อมต่อกับ Git

2. ถ้าอ็อบเจ็กต์ที่อ้างอิงทุกชิ้นมีอยู่จริงและไม่มีคอลัมน์ใดที่คลุมเครือจริง ๆ ผู้สมัครจะเป็น :: ปัญหาที่ทราบกันดีในการตรวจสอบความถูกต้องที่เกิดขึ้นระหว่างการคอมมิตและอัปเดตจาก Git ซึ่งทีมผลิตภัณฑ์ติดตามอยู่ ลองวิธีแก้ไขเหล่านี้ตามลําดับ:

   1. แทนที่ SELECT * CTE ภายในและตารางที่สร้างขึ้นด้วยรายการคอลัมน์ที่ชัดเจน
   2. แบ่งมุมมองเพื่อให้แต่ละแหล่งที่มาที่คลุมเครือถูกกําหนดในมุมมองของตัวเอง และอ้างอิงมุมมองนั้นแทนที่จะทําซ้ําคําค้นพื้นฐาน
   3. หลีกเลี่ยงการเชื่อมต่อกับ OPENROWSET(BULK ...) แหล่งที่มีรูปร่างแบบไดนามิกอื่นในคําสั่งเดียวกัน

หากไม่มีวิธีใดแก้ไขข้อผิดพลาดได้ ให้รวบรวมคํานิยามของวัตถุที่ระบุในข้อผิดพลาดและเปิดคําขอสนับสนุน สําหรับข้อจํากัดเฉพาะของสายงานการปรับใช้ โปรดดูที่ ข้อจํากัด

เนื้อหาที่เกี่ยวข้อง

• เริ่มต้นใช้งานการรวม Git
• ใช้ Git Integration สําหรับการพัฒนาและปรับใช้คลังสินค้า