SQL Compare是一款比較和同步SQL Server數據庫結構的工具。現有超過150,000的數據庫管理員、開發人員和測試人員在使用它。當測試本地數據庫，暫存或激活遠程服務器的數據庫時，SQL Compare將分配數據庫的過程自動化。

點擊下載SQL Compare試用版

在開發過程中可能會發生由違反約束引起的構建錯誤，您通常會在其中構建數據庫，臨時禁用約束，批量導入測試數據并重新啟用約束，以使它們“受信任”。例如，如果有人在不更新約束定義的情況下弄亂了測試數據，那么重新啟用約束會導致構建錯誤。如果在現有數據庫中部署對表約束的更改，并且以前有一些“不良數據”潛入這些表中，則可能會遇到類似的問題。一旦部署失敗，處理問題就不可避免地會導致中斷，而有人則逐個錯誤地識別并修復每行不良數據。

本文將向您展示如何在SQL Compare部署期間通過預先找出所有沖突的行并開發腳本來修復數據來防止約束沖突“破壞構建” 。偵探工作由一些自定義存儲過程完成，這些存儲過程從源數據庫中提取約束元數據（并將其保存在JSON約束文檔中），然后針對新的約束定義“測試”目標數據庫中的數據。這將生成一個預先報告，列出哪些數據行（如果有）將在后續部署期間導致約束沖突，以及原因。有了這些，您可以開發腳本來修復錯誤的數據，從而避免任何錯誤。

在開發構建期間，您可以批量加載數據，對其進行測試并運行腳本以修復任何沖突的行以及可重新啟用的約束。將更改部署到其他數據庫時，可以使用JSON約束文檔來測試目標數據庫中的數據。您可以使用SQL Compare部署前腳本來修復數據，或者可能更安全，首先以“禁用”狀態部署任何新約束，然后使用SQL Compare部署后腳本來修復數據然后啟用它們。

為什么要擔心約束和不良數據？

約束以某種方式限制了列或列組合中允許的值。一個FOREIGN KEY約束限制值，那些已經在引用表中存在。一個UNIQUE約束者禁用副本（如果用戶要求在亞利桑那州目前的銷售稅率，他們想要一個答案，而不是三個）。一個CHECK約束限制值，那些對自己有意義的業務。換句話說，這里有保護您數據完整性和一致性的工具。他們對數據進行監管，以確保其中不包含錯誤，歧義和誤解。

但是，當您在開發過程中構建數據庫的新版本或將更改部署到現有數據庫時，為保護數據而正確添加的約束也會使您的速度變慢。

在開發過程中破壞構建

在開發工作期間，一旦使用SQL Compare構建了新版本的數據庫架構，就需要加載測試數據。但是，您可能會遇到問題。首先，FOREIGN KEY約束將迫使您以反向依賴的順序填充表，從不引用其他表的表開始。其次，SQL Server將在插入行時根據現有約束嚴格檢查每一行，并在第一次違反時中止任務。
消息547，級別16，狀態0，第2行
ALTER TABLE語句與CHECK約束“ CK_Employee_MaritalStatus”沖突。數據庫“ AdventureWorks”的表“ HumanResources.Employee”的“ MaritalStatus”列中發生了沖突

看來數據在該MaritalStatus列中包含一些意外值。您需要找到并修復沖突的行，然后重試。

在加載數據之前，禁用所有約束和唯一的非聚簇索引會更加輕松快捷。這等效于管理麻醉劑的數據庫。您可以加載數據并進行修改，而不會引起抗議，然后重新啟用所有約束，并添加option WITH CHECK，這意味著SQL Server將立即檢查所有數據以確保其符合所有現有表約束（您可以d還需要重建任何重建的唯一非聚集索引（如果禁用了它們）。

EXEC sp_msforeachtable 'ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all'

在重新啟用所有約束之前，首先要列出所有未通過約束的行。在開發構建期間，我們將與目標數據庫建立連接，因此我們只需運行新構建，禁用約束，加載數據，針對實時約束元數據對其進行測試，并設計一個腳本以在重新啟用約束之前進行修復。

中斷對現有數據庫的部署

想象一下，您進行了一些開發更改，從而改善了AdventureWorks中某些表的約束。所有這些都可以與您的測試數據集很好地配合，因此您可以使用SQL Compare生成部署腳本，在必要時進行測試和修改，然后將其交付給您的Ops團隊。他們需要在暫存中進行全部測試，該暫存具有真實數據的副本，其中許多數據必然受到限制并且無法用于開發。

構建失敗，Ops團隊向您發送了一個包含錯誤的報告，就像我們之前看到的那樣。似乎某些現有數據違反了新的約束定義，但是錯誤消息只會告訴您約束條件失敗的第一行，而不是全部。您修復了該行，并且每次嘗試啟用約束時WITH CHECK都會遇到另一個錯誤。

在這個階段，您或Ops團隊如果無法完全訪問生產數據，則需要逐行檢查所有這些錯誤，并提出一個腳本來修復數據。

或者，如果在運行部署之前向開發團隊提供了將失敗新約束的所有行以及唯一的非聚集索引的列表，則可以避免這種情況。Ops團隊可以針對即將部署的以JSON格式存儲的約束元數據測試實時數據。這將生成報告，讓開發人員知道哪些值會導致問題，以便他們可以在生成以下內容之前生成“數據清理”腳本來修復所有約束問題，檢查約束，唯一約束和外鍵約束。發布。

如何檢查和獲取約束報告

無論是將數據庫更新到新版本，還是保留數據，還是從頭開始構建新版本，然后加載數據，約束錯誤，重復錯誤和參考錯誤的發生頻率都令人驚訝。您已經部署了新的數據庫版本，但是表并沒有改變，但是您面對著一個充滿紅色的消息窗格。也許有人厭倦了重復出現的重復行，合理而合理地收緊了約束。

為了避免所有這些，我們需要運行一系列稍有不同的測試，以便進行捕獲：

• 錯誤的數據檢查 -對于可能違反CHECK約束條件的行
• 重復檢查 –查找違反UNIQUE顧問或非聚集索引的行。
• 關系完整性檢查 –對于違反FOREIGN KEY約束的行

壞消息是它需要編寫腳本，主要是使用SQL。好消息是，我已經為您完成了此任務，并將其放入我的公共Github存儲庫中。我在一系列簡單文章中描述了它的工作方式：但是數據庫在開發中起作用！防止破壞約束，但是數據庫在開發中起作用了！避免重復的行，但是數據庫在開發中正常工作！檢查參照完整性。

對于每種類型的檢查，只有兩個存儲過程可以完成工作。名為的臨時存儲過程#List*將在系統目錄視圖中查詢索引或約束元數據，并將其以JSON格式存儲。名為的相應臨時存儲過程將#Test*執行其相應#List*過程，運行檢查并生成報告。

例如，獲取有關本地目標數據庫中哪些行違反了哪些CHECK約束的詳細報告，如下所示：

DECLARE @OurFailedConstraints  NVARCHAR(MAX)
 EXECUTE #TestAllCheckConstraints @TheResult=@OurFailedConstraints OUTPUT
 SELECT @OurFailedConstraints AS theFailedCheckConstraints

• TestLoadedDataForCheckConstraints.sql
• TestLoadedDataForFKConstraints.sql和
• TestLoadedDataForUniqueConstraints.sql

我還在回購中包含了一個名為ExecuteConstraintsCode.ps1的PowerShell文件，該文件包含一個Assert-Constraints函數，一旦完成所有設置，所有這些檢查將變得更加容易。您只需將以上三個文件放在目錄中，函數就會將它們放起來并執行。稍后將顯示一些示例。

一個簡單的演練：檢查違反約束的情況

讓我們來看一個簡單的示例，使用SQL Compare可以解決問題。我們將假裝AdventureWorks業務告訴我們，一名員工已超出其65小時病假的年度津貼，而人力資源部門卻不知道。現有的限制允許0到120小時，因此需要解決。

開發人員Dave修改了employee表以解決此問題，并檢入代碼：

ALTER TABLE [HumanResources].[Employee]  WITH CHECK ADD  CONSTRAINT [CK_Employee_SickLeaveHours] CHECK  (([SickLeaveHours]>=(0) AND [SickLeaveHours]<=(65)))

他們檢查排序規則是否設置為相同，然后運行SQL Compare。它檢測到開發人員Dave的更改。

PRINT N'Adding constraints to [HumanResources].[Employee]'
GO
ALTER TABLE [HumanResources].[Employee] ADD CONSTRAINT [CK_Employee_SickLeaveHours] CHECK (([SickLeaveHours]>=(0) AND [SickLeaveHours]<=(65)))
GO
IF @@ERROR <> 0 SET NOEXEC ON
GO

現在，讓我們看看在兩種情況下，他們如何都能獲得JSON報告，該報告將為您提供違反約束條件的行的所有詳細信息，您可以從中準備在發生錯誤之前修復數據的遷移腳本。
在開發構建過程中檢查約束是否違反

我們假設團隊希望從源代碼管理中的腳本開始，在其中包含數據的工作數據庫。我們假設他們已經在目錄中準備好了開發數據的副本。請參考此處的操作方法。
該過程如下所示：

部署SQL Server數據庫時，SQL Compare可以通過兩種相當不同的方式（即構建和同步）用于部署。它可以更改現有目標數據庫的模式以匹配源。如果開發人員正在構建新數據庫，則目標數據庫為空，因此部署腳本將修改空（model）數據庫架構，使其與源數據庫匹配。如果您要編寫腳本以供常規使用，請使用SQL Compare CLI，或使用文檔更改，代碼分析檢查等更健壯的過程，請使用SQL Change Automation。

這是一個非常簡單的PowerShell腳本，用于使用SQL Compare CLI構建具有新約束的新數據庫。您需要填寫SQL Compare的路徑，并指定從中獲取它的服務器和數據庫。如果您使用集成的安全性$MyUserId和$MyPassword對$null，否則填充它們：

Set-Alias SQLCompare "${env:ProgramFiles(x86)}\Red Gate\SQL Compare 13\sqlcompare.exe" -Scope Script
$MyServerInstance='MyServer'#The SQL Server instance
$MySourceDatabase='MyDatabase' #The name of the database
$MySourceDatabasePath = "$($env:HOMEDRIVE)$($env:HOMEPATH)\Documents\GitHub\$MySourceDatabase"
$MyNewDatabase = 'TargetDatabase'
$MyUserId='MyUserID'  #fill this in if you need credentials
$MyPassword='MyPassword' #fill this in if you need credentials
 #------
if ($MyUserId -ne $NULL)
    {
    SQLCompare /scripts1:$MySourceDatabasePath /username2:$MyUserId /Password2:$MyPassword `
               /database2:$MyNewDatabase /server2:$MyServerInstance /force
    }
else
    {
    SQLCompare /scripts1:$MySourceDatabasePath `
               /database2:$MyNewDatabase /server2:$MyServerInstance /force
    }
 if ($?) {'That went well'}
 else {"That Went Badly (code $LASTEXITCODE)"}

為了避免新外鍵或檢查約束出現錯誤，直到我們有足夠的時間來識別和修復它們之前，我們需要禁用所有外鍵或檢查約束。

EXEC sp_msforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT all"

SELECT  'Alter Index '+IX.name+ ' ON '+QuoteName(Object_Schema_Name(tabs.object_id))+'.'+QuoteName(tabs.name)+ ' DISABLE'    AS Statement
         FROM sys.tables AS tabs
          INNER JOIN sys.indexes AS IX
            ON IX.object_id = tabs.object_id
      WHERE (IX.is_unique_constraint =1) OR (IX.type=2 AND IX.is_unique=1)

ALTER TABLE [HumanResources].[Employee] WITH NOCHECK ADD CONSTRAINT [CK_Employee_SickLeaveHours]
CHECK (([SickLeaveHours]>=(0) AND [SickLeaveHours]<=(65)))

ALTER INDEX [AK_SalesTaxRate_StateProvinceID_TaxType] ON [Sales].[SalesTaxRate] DISABLE

3.加載數據

現在，我們需要獲取數據。我們可以使用我作為“ 在SQL Server數據庫和服務器之間復制所有數據”而發布的腳本。

盡管使用命令行BCP實用程序的本機BCP是最快的方法，但這絕不是唯一的方法。我已經發布了很多有關使用JSON的信息。無論采用哪種數據存儲介質，都可以使用其大容量加載庫Data.SqlClient.SqlBulkCopy來導入DataTables，Datareaders或數據行數組。用外行的話來說，任何可以表示為表格的東西都可以批量導入。當需要“即時”清理時，我什至可以使用它導入CSV，然后在完成后將其啟用。

4.測試數據是否違反約束

開發構建是最簡單的情況，因為團隊正在檢查已與新版本同步或從新版本構建的本地目標數據庫，但未啟用新的約束或啟用唯一的非聚集索引。

這是一個相對簡單的過程，因為您無需獲取或存儲JSON約束文檔，因為您只需檢查目標數據庫中的元數據并運行測試即可。如果您對保存報告不感興趣，請加載所有臨時存儲過程并執行：

DECLARE @OurFailedConstraints  NVARCHAR(MAX)
 EXECUTE #TestAllCheckConstraints @TheResult=@OurFailedConstraints OUTPUT
 SELECT @OurFailedConstraints AS theFailedCheckConstraints
EXECUTE # #TestAllUniqueConstraints @TheResult=@OurFailedConstraints OUTPUT
 SELECT @OurFailedConstraints AS theFailedCheckConstraints
EXECUTE #TestAllForeignKeyConstraints @TheResult=@OurFailedConstraints OUTPUT
 SELECT @OurFailedConstraints AS theFailedCheckConstraints

[
  {
    "success": "There were 1  check constraints that would fail data and no errors",
    "FailedChecks": [
      {
        "BadData": {
          "RowsFailed": "25",
          "ConstraintName": "[CK_Employee_SickLeaveHours]",
          "ConstraintTable": "[HumanResources].[Employee]",
          "Expression": "([SickLeaveHours]>=(0) AND [SickLeaveHours]<=(65))",
          "BadDataSample": [
            {
              "BusinessEntityID": 1,
              "NationalIDNumber": "295847284",
              "LoginID": "adventure-works\\ken0",
              "JobTitle": "Chief Executive Officer",
              "BirthDate": "1969-01-29",
              "MaritalStatus": "S",
              "Gender": "M",
              "HireDate": "2009-01-14",
              "SalariedFlag": true,
              "VacationHours": 99,
              "SickLeaveHours": 69,
              "CurrentFlag": true,
              "rowguid": "F01251E5-96A3-448D-981E-0F99D789110D",
              "ModifiedDate": "2014-06-30T00:00:00"
            },
…etc…
]

現在，您設計了一個腳本，該腳本將修改所報告的數據行，以使其符合恒定條件，在新建并填充的數據庫上運行它，然后重新啟用所有外鍵或檢查約束。

EXEC sp_msforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"

ALTER INDEX [AK_SalesTaxRate_StateProvinceID_TaxType] ON [Sales].[SalesTaxRate] REBUILD

關系數據庫在結構（模式）和數據之間有很強的區別。其他類型的數據庫并非如此，這可能會引起混亂。盡管SQL Compare盡最大努力將目標數據庫中的現有數據保留下來，但它無法做任何事情來使其與新的約束或唯一索引匹配，并且無法保證該數據現在有效。

無論您是否連接到目標數據庫，我們都將討論該過程如何工作。這次，我們將看到如何使用PowerShell獲取JSON報告，該報告將預先告知正在部署的更改對數據的全部影響。
在連接的目標數據庫中查找違規行

使用直接連接到目標數據庫運行同步的情況更簡單。再次，我們通過構建一個空數據庫然后禁用其約束和唯一索引來進行統計。但是，此數據庫現在成為與目標數據和現有數據同步的源。如前所述，SQL Compare將生成一個部署腳本，當將其應用于目標時，將使約束和唯一索引保持“關閉”狀態。完成此操作后，過程將像以前一樣進行：

Assert-Constraints @(
 <# list of connection strings for each of the SQLservers that you need to execute code on #>
    @{
        'ServerConnectionString' = 'Server=MyServer;User Id=MyName;Persist Security Info=False';
        #and a list of databases you wish the string-based (EG JSON report) from. 
        'Databases' = @('Shadrak', 'Meshak', 'Abednego'); # do all these databases
        'RootDirectoryForOutputFile' = "$env:USERPROFILE\JSONDocumentation"; #the directory you want it in as subdirectories
        'minimumCompatibilityLevel' = 130; #specify the minimum database compatibility level. We check!
        'ScriptDirectory' = 'D:\Github\TestOutConstraints'; # where you store the project SQL files 
        'fileType' = 'json'; #the filetype of the files you save for each database for reports
        # and now a list of all the temporary stored procedures you'll need.
        'setupScripts' = @(
          'ListAllUniqueIndexes.sql', 'ListAllForeignKeyConstraints.sql', 'ListAllCheckConstraints.sql',
          'TestAllUniqueIndexes.sql', 'TestAllForeignKeyConstraints.sql', 'TestAllCheckConstraints.sql');
    <#This lot are used process 1- for testing the loaded data to ensure it complies with the constraints#>
        'FilesToExecute' = @(
            @{
                'scriptFileName' = 'TestLoadedDataForCheckConstraints.sql'; `
                'OutputFileName' = 'CheckConstraintsReport'
            },
            @{
                'scriptFileName' = 'TestLoadedDataForUniqueConstraints.sql'; `
                'OutputFileName' = 'UniqueConstraintsReport'
            },
            @{
                'scriptFileName' = 'TestLoadedDataForFKConstraints.sql'; `
                'OutputFileName' = 'FKConstraintsReport'
            }
        )
        'TearDownScripts' = @();
    }
)

有了報告，您就可以開發數據遷移腳本，運行它并重新啟用所有約束和索引，以使它們受到信任。

使用JSON約束文件查找違規行

當然，有時候您無法開發數據遷移腳本并無法以這種方式來部署更改，而無法直接連接到目標，例如在部署到生產時。同樣，在某些情況下，開發團隊也無法訪問Staging，而需要將部署腳本傳遞給Ops團隊進行測試。

在這種情況下，開發團隊將根據數據庫的新版本創建必要的JSON約束腳本文件，而Ops團隊將使用該文件來測試當前版本的Staging中的數據，并創建數據遷移腳本或發送向開發團隊返回報告，以便他們能夠做到。

Assert-Constraints @(
 <# list of connection strings for each of the SQLservers that you need to execute code on #>
  @{
    'ServerConnectionString' = 'Server=MyServer;User Id=PhilFactor;Persist Security Info=False';
    #and a list of databases you wish the string-based (EG JSON report) from. 
    'Databases' = @('NewAdventureworks2016'); # the database we do it on
    'RootDirectoryForOutputFile' = "$env:USERPROFILE\ConstraintDemo"; #the directory you want it in as subdirectories
    'minimumCompatibilityLevel' = 130; #specify the minimum database compatibility level. We check!
    'ScriptDirectory' = 'D:\Github\TestOutConstraints'; # where you store the project SQL files 
    'fileType' = 'json'; #the filetype of the files you save for each database for reports
    # and now a list of all the temporary stored procedures you'll need.
    'setupScripts' = @('ListAllUniqueIndexes.sql', 'ListAllForeignKeyConstraints.sql', 'ListAllCheckConstraints.sql',
      'TestAllUniqueIndexes.sql', 'TestAllForeignKeyConstraints.sql', 'TestAllCheckConstraints.sql');
    
    <#Save the lists of constraints as defined in the database #>
    'FilesToExecute' = @(
      @{
        'scriptFileName' = 'GetListofAllForeignKeyConstraints.sql'; `
        'OutputFileName' = 'FKConstraintsList.JSON'
      },
      @{
        'scriptFileName' = 'GetListofAllUniqueConstraints.sql'; `
        'OutputFileName' = 'UniqueConstraintsList.JSON'
      },
      @{
        'scriptFileName' = 'GetListofAllCheckConstraints.sql'; `
        'OutputFileName' = 'CheckConstraintsList.JSON'
      }
    )
    'TearDownScripts' = @();
  }
)

Assert-Constraints @(
 <# list of connection strings for each of the SQLservers that you need to execute code on #>
  @{
    'ServerConnectionString' = 'Server=MyOtherServer;User Id=PhilFactor;Persist Security Info=False';
    #and a list of databases you wish the string-based (EG JSON report) from. 
    'Databases' = @('Adventureworks2016'); # do all these databases
    'RootDirectoryForOutputFile' = "$env:USERPROFILE\ConstraintDemo"; #the directory you want it in as subdirectories
    'minimumCompatibilityLevel' = 130; #specify the minimum database compatibility level. We check!
    'ScriptDirectory' = 'D:\Github\TestOutConstraints'; # where you store the project SQL files 
    'fileType' = 'json'; #the filetype of the files you save for each database for reports
    # and now a list of all the temporary stored procedures you'll need.
    'setupScripts' = @('ListAllUniqueIndexes.sql', 'ListAllForeignKeyConstraints.sql', 'ListAllCheckConstraints.sql',
      'TestAllUniqueIndexes.sql', 'TestAllForeignKeyConstraints.sql', 'TestAllCheckConstraints.sql');
    
    <#Save the lists of constraints as defined in the database #>
    'FilesToExecute' = @(
          @{
            'scriptFileName' = 'TestJSONForUniqueIndexes.sql'; `
            'input' = @{ 'FileName' = 'UniqueConstraintsList.json' }; `
            'OutputFileName' = 'DelayedUniqueConstraintsReport'
          },
            @{
            'scriptFileName' = 'TestJSONForCheckConstraints.sql'; `
            'input' = @{ 'FileName' = 'CheckConstraintsList.json' }; `
            'OutputFileName' = 'DelayedCheckConstraintsReport'
          },
            @{
            'scriptFileName' = 'TestJSONForForeignKeyConstraints.sql'; `
            'input' = @{ 'FileName' = 'FKConstraintsList.json' }; `
            'OutputFileName' = 'DelayedFKConstraintsReport'
          }    )
            'TearDownScripts' = @();
          }
)

現在在Adventureworks2016數據庫上運行腳本S：\ work \ Github \ TestOutConstraints \ TestJSONForUniqueIndexes.sql
警告：有2個索引與數據不匹配且沒有錯誤
現在在Adventureworks2016數據庫上運行腳本D：\ Github \ TestOutConstraints \ TestJSONForCheckConstraints.sql
警告：有1個檢查約束，它們將使數據失敗并且沒有錯誤
現在在Adventureworks2016數據庫上運行腳本D：\ Github \ TestOutConstraints \ TestJSONForForeignKeyConstraints.sql

這里有違反約束條件的行的完整報告。我向檢查約束違例添加了幾個索引重復項：

[
  {
    "success": "There were 1  check constraints that would fail data and no errors",
    "FailedChecks": [
      {
        "BadData": {
          "RowsFailed": "25",
          "ConstraintName": "[CK_Employee_SickLeaveHours]",
          "ConstraintTable": "[HumanResources].[Employee]",
          "Expression": "([SickLeaveHours]>=(0) AND [SickLeaveHours]<=(65))",
          "BadDataSample": [
            {
              "BusinessEntityID": 1,
              "NationalIDNumber": "295847284",
              "LoginID": "adventure-works\\ken0",
              "JobTitle": "Chief Executive Officer",
              "BirthDate": "1969-01-29",
              "MaritalStatus": "S",
              "Gender": "M",
              "HireDate": "2009-01-14",
              "SalariedFlag": true,
              "VacationHours": 99,
              "SickLeaveHours": 69,
              "CurrentFlag": true,
              "rowguid": "F01251E5-96A3-448D-981E-0F99D789110D",
              "ModifiedDate": "2014-06-30T00:00:00"
            },
            {
              "BusinessEntityID": 4,
              "NationalIDNumber": "112457891",
              "LoginID": "adventure-works\\rob0",
              "OrganizationNode": "/1/1/1/",
              "OrganizationLevel": 3,
              "JobTitle": "Senior Tool Designer",
              "BirthDate": "1974-12-23",
              "MaritalStatus": "S",
              "Gender": "M",
              "HireDate": "2007-12-05",
              "SalariedFlag": false,
              "VacationHours": 48,
              "SickLeaveHours": 80,
              "CurrentFlag": true,
              "rowguid": "59747955-87B8-443F-8ED4-F8AD3AFDF3A9",
              "ModifiedDate": "2014-06-30T00:00:00"
            },
            {
              "BusinessEntityID": 88,
              "NationalIDNumber": "294148271",
              "LoginID": "adventure-works\\betsy0",
              "OrganizationNode": "/3/1/8/1/",
              "OrganizationLevel": 4,
              "JobTitle": "Production Technician - WC10",
              "BirthDate": "1966-12-17",
              "MaritalStatus": "S",
              "Gender": "F",
              "HireDate": "2009-12-18",
              "SalariedFlag": false,
              "VacationHours": 99,
              "SickLeaveHours": 69,
              "CurrentFlag": true,
              "rowguid": "EBCDBA1C-6C1D-4D36-90F7-1893755C85E3",
              "ModifiedDate": "2014-06-30T00:00:00"
            }
          ]
        }
      }
    ]
  }
]

運行自動化部署

在自動部署過程中部署新約束時，您可以選擇何時修復數據。

您可以將數據遷移腳本作為SQL Compare（或SQL Change Automation）預部署腳本來運行。請小心遵守部署前代碼的規則：對錯誤進行自己的回滾，并遵守在出現錯誤時進行設置的約定NOEXEC。但是，如果運行了部署前腳本，但隨后的部署失敗了怎么辦？

如前所述，替代方法是將更改后的約束和唯一索引提交到處于禁用狀態的源代碼控制。在這種情況下，您可以使用SQL Compare或SQL Change Automation 將數據遷移腳本作為部署后腳本的一部分運行，然后再重新啟用約束和索引并檢查它們是否都“受信任”。部署完成。

摘要

即使源數據庫和目標數據庫具有相同的表名和列，也無法保證可以成功將數據從一個復制到另一個。如果您要從其他來源（例如外部應用程序）加載數據，則所有選擇均無效。為什么是這樣？這是由于目標數據庫中的限制而導致的，這些數據庫選擇了重復項，不良數據以及參照完整性問題。這些必須解決，否則您將始終面臨性能缺陷。您可能還會因數據問題而遭受更嚴重的打擊。如果您作為開發人員沒有直接訪問數據的權限，或者作為操作人員沒有時間或專門知識來完成這項工作，那一切都會變得更糟。

這段代碼旨在防止發生此類問題。它根據目標數據庫中的約束檢查數據，并為您提供在啟用約束之前或在啟動自動化過程（如自動化構建）之前需要修復的數據列表。

相關產品推薦：

SQL Prompt：SQL語法提示工具

SQL Toolbelt：Red Gate產品套包

SQL Monitor：SQL Server監控工具