可更新訂閱為什麽有沖突？

可更新訂閱中，當升級增加一個字段時，通常在發布服務器的發布數據庫中增加，對表增加字段後，發布自動同步到訂閱數據庫中（復制架構更改=true）。但是，如果此時在訂閱數據庫進行DML操作，數據將不會同步到發布表中；這些差異數據在訂閱表中如果一直未進行DML 操作，也就不會再次同步到發布中，存在差異。

復制配置環境：

可更新訂閱事務復制

發布和訂閱沖突都以訂閱為準

使用排隊更新

在訂閱操作

沖突測試結果（以下為： 當數據存在不一致的情況下，對訂閱再次操作會引起沖突，沖突策略會自動解決）：

當發布數據不存在，訂閱數據存在時，此時更新訂閱數據：（排隊更新沖突）

當發布和訂閱主鍵相同，msrepl_tran_version不同時，此時更新訂閱數據：（排隊更新沖突）

以上兩種情況結果：

在發布沖突，沖突表記錄值都為最新值，訂閱數據更新或插入到發布表中。

當發布數據不存在，訂閱數據存在時，此時刪除訂閱數據：（排隊更新沖突）

當發布和訂閱主鍵相同，msrepl_tran_version不同時，此時刪除訂閱數據：（排隊更新沖突）

以上兩種情況結果：

刪除操作同步到發布時沖突。

沖突入選方：

此行不再存在於“[dbo].[TestTab]”中。 [[dbo].[TestTab]].[qcfttabrowid] 中唯一 ID 的值是“8d335a44-36a0-432c-bba4-4979df3c804e”。

沖突落選方：

嘗試刪除此位置上的此數據時出現上述錯誤，原因可能是此刪除操作違反了一個或多個約束。如果您忽略此沖突，則應通過其他方式加以解決。您可以記錄此沖突的詳細信息，然後將日誌條目發送給系統管理員。

架構更如何防止沖突？

若要在支持更新訂閱的發布中的表上進行架構更改，必須在發布服務器和訂閱服務器中停止該表上的所有活動，還必須將掛起的數據更改傳播到所有節點，然後才能進行架構更改。這可以確保未完成的事務不會與掛起的架構更改發生沖突。架構更改傳播到所有節點後，可以在已發布的表上恢復活動。如何停止復制拓撲（復制 Transact-SQL 編程）

本人測試了一種解決方案：SQLServer 可更新訂閱數據在線架構更改（增加字段）方案

參考: 事務復制的可更新訂閱

SQLServer 可更新訂閱數據沖突的一個原因