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

Question

我们遇到合并复制问题.我们的发布者运行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)"

Answer 1

它是sql 2008中的一个新功能,因此在2005年不受支​​持.根据您的设置有多复杂,您可能需要考虑让您的数据库在兼容性90(sql 2005)中运行,以确保您不将sql 2008功能添加到您的数据库.模式数据的复制问题一直存在很大问题,因为它总是有点沉默寡言.我总是尝试让它变得愚蠢而且只管理数据 - 必须支持具有32个订阅者的合并系统以及合并复制,并且当我们推动架构更改时,它们会不断出现大的架构问题.

也就是说,如果它按照记录的方式工作,它不应该试图推动你的锁更改.检查订阅是否标记为sql 2005兼容.可能他们没有按照他们对数据类型的方式创建2008年到2005年的设置自动地图(例如)

其中一个SQL开发人员在一段时间之后发表了关于新锁定类型的博客