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

Question

我们在合并复制方面遇到了问题。我们的发布者运行 SQL Server 2008，而我们的两个订阅者运行 2005。我们的出版商正在尝试发送 ALTER TABLE Foo SET (LOCK_ESCALATION) 向我们的订阅者发出命令。我想我记得读到过这个命令是 SQL Server 2008 中的新命令，如果是这样，那么该命令在我们的 2005 服务器上失败是有道理的。然而，我们的合并复制是为了兼容 2005 年而设置的。

架构脚本'如果Object_id（n'[dbo]。[用户]'）不是null exec（'alter table [dbo]。[用户] set（lock_escalation = table）'）'无法传播到订户。

关于为什么我们的出版商会尝试这样做有什么想法吗？

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

Answer 1

它是 sql 2008 中的新功能，因此 2005 年不支持。根据您的设置的复杂程度，您可能需要考虑让数据库在兼容性 90 (sql 2005) 中运行，以确保不会将 sql 2008 功能添加到数据库中。自从模式数据出现以来，它就遇到了很大的问题，所以总是有点沉默寡言。我总是尝试让它表现得愚蠢，只管理数据 - 必须通过合并复制支持具有 32 个订阅者的合并系统，并且当我们推送模式更改时不断出现大模式问题。

也就是说，如果它按照记录工作，那么它不应该尝试推动您的锁更改。检查订阅是否标记为 sql 2005 兼容。他们很可能没有像处理数据类型那样创建 2008 年到 2005 年设置的自动地图（例如）

SQL 开发人员之一 写博客 不久前关于新的锁定类型

Answer 2

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

有两种方法：删除并重新创建suscription，当它在生产服务器中时不适用。第二种方法是转到数据库中的 sysmergeschemachange 表，并删除具有以下内容的行：

  

架构脚本'if   object_id（N'[dbo]。[Users]'）不是   null exec（'ALTER TABLE [dbo]。[用户]   SET（LOCK_ESCALATION = TABLE）'）'   无法传播到   订户。

我希望这会有所帮助。