爲什麼在設置表的LOCK_ESCALATION時合併複製失敗？

我們遇到了合併複製問題。我們的發佈商運行SQL Server 2008，而我們的兩個訂戶運行2005.我們的發佈商正在嘗試向訂戶發送ALTER TABLE Foo SET (LOCK_ESCALATION)命令。我想我記得讀過這個命令在SQL Server 2008中是新的，如果是這樣的話，這個命令在我們的2005服務器上會失敗。但是，我們的合併複製設置爲2005年兼容性。爲什麼在設置表的LOCK_ESCALATION時合併複製失敗？

'如果OBJECT_ID（N' 架構腳本[DBO]。[用戶] '）不是空的exec（' ALTER TABLE [DBO]。[用戶] SET（LOCK_ESCALATION = TABLE） '）' 能不會傳播給訂閱者。

關於爲什麼我們的出版商會試圖做到這一點的任何想法？

編輯：我們2008服務器的兼容性級別設置爲「SQL Server 2005的（90）」

來源

2009-05-01 Samantha Branham

SQL Server 2008中的確認錯誤。直到SQL Server 2011才能修復。（https://connect.microsoft.com/SQLServer/feedback/details/536571） – hangy 2011-02-14 09:46:07

它在SQL 2008中的新功能，以便在2005年不支持根據您的設置有多複雜，你可能想要考慮讓你的數據庫運行在兼容性90（SQL 2005），以確保你不添加SQL 2008功能到你的數據庫。自從有了模式數據的複製以來，它一直有點沉默，因此在複製模式數據方面遇到了很大的問題。我總是試圖讓它變得愚蠢，只是管理數據 - 必須支持具有合併複製的32位訂閱者的合併系統，並且在我們推送模式更改時不斷有大型模式問題。

這就是說，如果它按照記錄工作，它不應該試圖推動你的鎖更改。檢查訂閱是否標記爲SQL 2005兼容。它有可能他們還沒有在他們爲數據類型（例如）

一對新的鎖定類型的SQL開發傢伙blogged的前陣子

的方式創建於2008年設定的自動映射到2005年

來源

2009-05-01 21:45:42 u07ch

感謝您確認我的懷疑並提醒我兼容性選項。不幸的是，我們的兼容級別*設置爲90. – 2009-05-01 21:55:50

已更新以供評論;它可能是2008年複製中的一個錯誤。它沒有在MSDN文章中記錄http://msdn.microsoft.com/en-us/library/ms143241.aspx – u07ch 2009-05-01 21:56:29

發生這種情況是因爲此指令與sql server 2005不兼容，而且當我在複製的表中進行模式更改時，會將此指令置於模式更改中。

有兩種方法：刪除並再次創建懷疑，當它位於生產服務器中時不適用。第二種方式是去sysmergeschemachange數據庫表中，並刪除具有像這樣的行：

架構腳本如果 OBJECT_ID（N'。[DBO] [網友]'）不是 null exec（'ALTER TABLE [dbo]。[Users] SET（LOCK_ESCALATION = TABLE）'）' 無法傳播到訂戶。

我希望這會有所幫助。

來源

2010-02-26 17:02:02

爲什麼在設置表的LOCK_ESCALATION時合併複製失敗？

回答

相關問題