删除复制表的外键约束

发布于 2024-10-12 05:07:22 字数 66 浏览 6 评论 0原文

我可以从参与合并复制的表中删除外键约束吗?如果是这样,我可以将其从已发布的内容中删除吗?此更改是否会复制到所有订阅者?

Can I drop a foreign key contraint from a table participating in merge replication? If so, can i just drop it from the published and will this chnage be replicated to all subscribes?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

在巴黎塔顶看东京樱花 2024-10-19 05:07:22

MSDN 上有一篇关于对发布数据库进行架构更改的专门

文章在这里间接讨论约束的放弃:

建议明确命名约束。如果未显式命名约束,SQL Server 会为该约束生成一个名称,并且这些名称在发布服务器和每个订阅服务器上都将不同。这可能会在复制架构更改期间导致问题。例如,如果您在发布服务器上删除一列,并且删除了从属约束,则复制将尝试在订阅服务器上删除该约束。由于约束的名称不同,订阅服务器上的删除将失败。如果由于约束命名问题导致同步失败,请手动删除订阅服务器上的约束,然后重新运行合并代理。

There's a dedicated article on MSDN around Making Schema Changes on Publication Databases

It does obliquely discuss the dropping of constraints, here:

It is recommended that constraints be explicitly named. If a constraint is not explicitly named, SQL Server generates a name for the constraint, and these names will be different on the Publisher and each Subscriber. This can cause issues during the replication of schema changes. For example, if you drop a column at the Publisher and a dependent constraint is dropped, replication will attempt to drop the constraint at the Subscriber. The drop at the Subscriber will fail because the name of the constraint is different. If synchronization fails because of a constraint naming issue, manually drop the constraint at the Subscriber and then rerun the Merge Agent.

情域 2024-10-19 05:07:22

我通过更改出版物上的文章属性来截断数据来解决这个问题,而不是删除并重新创建表。

完成此操作后,您需要生成一个新的快照。

干杯

I have solved this by changing the articles properties on the publication to truncate the data instead of dropping and recreating the tables.

U need to generate a new snapshot after doing that.

Cheers

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文