SQL合并复制:如何判断记录是否已被复制

发布于 2024-07-24 01:19:52 字数 323 浏览 4 评论 0原文

我有一个合并复制方案,其中 SQL2005 SP3 作为发布者和分发者,Windows Mobile SQLCE 3.5 SP1 作为订阅者。

复制过滤器使得表之一 (tblJobs) 中的行仅发送到一台设备。 设备复制后,它会执行 sql 以在其下载的所有记录上设置 IsSynced 布尔列,然后再次复制。

有什么方法可以避免第二次复制并在复制期间设置 IsSynced 布尔列? (也许先下载,设置标志,然后上传?或者也许让发布者/发行商上的复制过程设置标志?)。 我不知道这种事情的钩子在哪里。

可能值得一提的是该表有一个 rowversion 字段。

I have a merge replication scenario, with SQL2005 SP3 as the publisher and distributor and windows mobile SQLCE 3.5 SP1 as the subscribers.

The replication filter is such that rows from one of the tables (tblJobs) only go to exactly one device. After the device has replicated it executes sql to set the IsSynced boolean column on all the records it has downloaded, then it replicates again.

Is there any way I can avoid the second replication and have the IsSynced boolean column set during the replication?? (Maybe download first, set the flag, then upload? Or maybe have the replication process on the publisher/distributor set the flag?). I don't know where the hooks are for this sort of thing.

It might be worth mentioning the table has a rowversion field.

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

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

发布评论

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

评论(2

小草泠泠 2024-07-31 01:19:52

判断记录是否已被复制的最简单方法是检查 MSmerge_contents 表。 如果该行存在于该表中,则它之前已被复制。

当然,如果您想确保客户端拥有该行的最新版本,那么您需要在下表中挖掘生成编号:

MSmerge_replinfo
MSmerge_genhistory
MSmerge_contents
MSmerge_tombstone

每次数据更改时,合并复制都会通过分配来跟踪此更改一个新的一代数字来改变。 然后,发布者保留代号和每个订阅者已收到的代的列表。

只需对订阅者上的行数据进行批量更新,就会强制将该更改复制到发布者。

不幸的是,我不知道更新该列的简单方法,除非您首先不复制该列 - 也就是说,使用垂直(列)分区将其排除。

The easiest way to tell if a record has been replicated is to check the MSmerge_contents table. If the row exists in that table then it has been previously replicated.

Of course, if you want to ensure that the client has the latest version of the row then you'll need to do some digging in the following tables for generation numbers:

MSmerge_replinfo
MSmerge_genhistory
MSmerge_contents
MSmerge_tombstone

Every time data is changed, Merge replication keeps track of this change by assigning a new generation number to the change. The publisher then keeps a list of generation numbers and the generation that each subscriber has received.

Simply doing a batch update of row data on the subscriber will force that change to be replicated to the publisher.

Unfortunately, I don't know of an easy way to update that column unless you don't replicate that column in the first place - that is, exclude it using vertical (column) partitioning.

笙痞 2024-07-31 01:19:52

不确定您真正想要什么,但如果您想区分源自此实例的记录和通过复制从其他实例到达此处的记录,一种方法是使用表中的 Origin 列,并将其默认为每个服务器上的唯一值。

Not sure what you really want, but in case you want to tell apart those records that originated on this instance from the ones that arrived here from other instances via replication, one way to do this is to have an Origin column in your table and have it defaulted to a unique value on each of your servers.

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