为什么合并复制在设置表的LOCK_ESCALATION时失败？

Question

我们在合并复制方面有问题。我们的发行者运行Server 2008，而我们的两个订阅服务器运行2005年。我们的发布者正在尝试向订阅者发送一个ALTER TABLE Foo SET (LOCK_ESCALATION)命令。我记得我读过这个命令在Server 2008中是新的，如果是的话，这个命令在我们2005年的服务器上会失败是有道理的。但是，我们的合并复制是为了2005年的兼容性而设置的。

模式脚本'if object_id(N‘dbo.User’)不是null exec('ALTER dbo.Users SET (LOCK_ESCALATION = TABLE) ')‘不能传播到订阅服务器。

对我们的出版商为什么要这么做有什么想法吗？

编辑： 2008服务器的兼容性级别设置为“Server 2005 (90)”

Answer 1

这是sql 2008中的一个新特性，因此在2005年不受支持。取决于您的设置有多复杂，您可能需要考虑让数据库在兼容性90 (sql 2005)中运行，以确保不向数据库添加sql 2008功能。模式数据的复制自从出现以来就有了很大的问题，所以总是有点沉默。我总是试图让它变得愚蠢，只管理数据--必须支持具有合并复制的32个订阅者的合并系统，并且在我们推动模式更改时经常会出现大的模式问题。

也就是说，如果它像文档一样工作，它不应该试图推动您的锁更改。检查订阅是否标记为sql 2005兼容。很可能他们没有像对待数据类型那样创建2008到2005年设置的自动地图(例如)。

一段时间前，新锁定类型的SQL dev guys 博客之一

Answer 2

这是因为此指令与sql server 2005不兼容，而且当我在正在复制的表中进行模式更改时，会将此指令置于架构更改中。

有两种方法:移除并再次创建约束，当它在生产服务器中时不适用。第二种方法是转到数据库中的sysmergeschemachange表，并删除具有如下内容的行：

模式脚本'if object_id(N‘dbo.User’)不是null exec('ALTER dbo.Users SET (LOCK_ESCALATION = TABLE) ')‘不能传播到订阅服务器。

我希望这能帮到你。