为什么合并复制在设置表的 LOCK_ESCALATION 时失败？
我们在合并复制方面遇到了问题。 我们的发布者运行 SQL Server 2008，而我们的两个订阅者运行 2005。我们的发布者正在尝试向我们的订阅者发送 ALTER TABLE Foo SET (LOCK_ESCALATION) 命令。 我想我记得读到过这个命令是 SQL Server 2008 中的新命令，如果是这样，那么该命令在我们的 2005 服务器上失败是有道理的。 然而，我们的合并复制是为了兼容 2005 年而设置的。
架构脚本 'if object_id(N'[dbo].[Users]') is not null exec('ALTER TABLE [dbo].[Users] SET (LOCK_ESCALATION = TABLE) ')' 无法传播到订阅者。
关于为什么我们的出版商会尝试这样做有什么想法吗？
编辑：我们的 2008 服务器的兼容性级别设置为“Sql Server 2005 (90)”
We're having a problem with a merge replication. Our publisher runs SQL Server 2008, while our two subscribers run 2005. Our publisher is trying to send an ALTER TABLE Foo SET (LOCK_ESCALATION) command out to our subscribers. I think I remember reading that this command is new in SQL Server 2008, and if so, it makes sense that the command would fail on our 2005 servers. Our merge replication is set up for 2005 compatibility, however.
The schema script 'if object_id(N'[dbo].[Users]') is not null exec('ALTER TABLE [dbo].[Users] SET (LOCK_ESCALATION = TABLE)
')' could not be propagated to the subscriber.
Any ideas on why our publisher would be trying to do this?
Edit: Our 2008 server's compatibility level is set to "Sql Server 2005 (90)"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它是 sql 2008 中的新功能，因此在 2005 中不受支持。根据您的设置的复杂程度，您可能需要考虑让数据库在兼容性 90 (sql 2005) 中运行，以确保不会将 sql 2008 功能添加到数据库中。 自从模式数据出现以来，它就遇到了很大的问题，所以总是有点沉默寡言。 我总是尝试让它表现得愚蠢，只管理数据 - 必须通过合并复制支持具有 32 个订阅者的合并系统，并且当我们推送模式更改时不断出现大模式问题。
也就是说，如果它按照记录工作，那么它不应该尝试推动您的锁更改。 检查订阅是否标记为 sql 2005 兼容。 他们很可能没有像处理数据类型那样创建 2008 年到 2005 年设置的自动映射（例如）
SQL 开发人员之一 博客不久前介绍了新的锁定类型
Its a new feature in sql 2008 so not supported in 2005. Depending on how complex your setup is you may want to consider have your database run in compatibility 90 (sql 2005) to make sure you dont add sql 2008 features to your database. Have had big issues with replication of schema data ever since it came about so always a bit reticent. I always try and make it act dumb and just manage data - had to support a merge system with 32 subscribers with merge replication and had big schema issues constantly when we pushed schema changes.
That said if it works as documented it shouldn't be trying to push your lock change. Check the subscriptions are marked as sql 2005 compatible. Its likely they haven't created an auto map of the setting from 2008 to 2005 in the way they did for data types (for example)
One of the SQL dev guys blogged on the new locking types a while back
发生这种情况是因为该指令与 sql server 2005 不兼容，并且显然当我在正在复制的表中进行架构更改时，会将该指令放入架构更改中。
有两种方法： 删除并重新创建订阅，当它在生产服务器中时不适用。 第二种方法是转到数据库中的 sysmergeschemachange 表并删除具有如下内容的行：
我希望这有帮助。
This occurs because the incompatibility of this instruction with sql server 2005 and aparently when I do a schema change in a table that is replicating puts this instruction in the schema changes.
There are two ways: Remove and create again the suscription, not applicable when It's in production server. Second way is go to sysmergeschemachange table in the database and delete the row that has something like this:
I hope this helps.