为什么在设置表的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时合并复制失败？

回答

相关问题