我们遇到合并复制问题。我们的发布者运行SQL Server 2008，而我们的两个订阅者运行2005.我们的发布者正在尝试向我们的订阅者发送ALTER TABLE Foo SET (LOCK_ESCALATION)命令。我想我记得在SQL Server 2008中看到这个命令是新的，如果是这样，那么命令在我们的2005服务器上会失败是有意义的。但是，我们的合并复制是为2005兼容性而设置的。
架构脚本'if object_id（N'[dbo]。[Users]'）不是null exec（'ALTER TABLE [dbo]。[Users] SET（LOCK_ESCALATION = TABLE） '）'无法传播给订阅者。
关于我们的发布商为何会尝试这样做的任何想法？
编辑：我们2008服务器的兼容级别设置为“Sql Server 2005（90）”
答案 0 :(得分：5)
它是sql 2008中的一项新功能，因此在2005年不受支持。根据您的设置有多复杂，您可能需要考虑让您的数据库在兼容性90（sql 2005）中运行，以确保您不会将sql 2008功能添加到您的数据库。模式数据的复制问题一直存在很大问题，因为它总是有点沉默寡言。我总是尝试让它变得愚蠢而且只是管理数据 - 必须支持具有32个订阅者的合并系统，并且在推送模式更改时不断出现大型模式问题。
如果它按照文档记录的那样说它不应该试图推动你的锁更改。检查订阅是否标记为sql 2005兼容。可能他们没有按照他们对数据类型的方式创建2008年到2005年的设置自动地图（例如）
一段时间内关于新锁定类型的SQL开发人员blogged
答案 1 :(得分：4)
这是因为此指令与sql server 2005不兼容，而且当我在复制的表中进行模式更改时，显然会将此指令置于架构更改中。
有两种方法：删除并重新创建suscription，当它在生产服务器中时不适用。第二种方法是转到数据库中的 sysmergeschemachange 表，并删除具有以下内容的行：
架构脚本'if object_id（N'[dbo]。[Users]'）不是 null exec（'ALTER TABLE [dbo]。[用户] SET（LOCK_ESCALATION = TABLE）'）' 无法传播到 订户。
我希望这会有所帮助。