我在 CRM 系统上设置了合并复制。销售代表数据在连接到网络时合并（我认为当 SQL 检测到笔记本电脑已连接时），然后他们将笔记本电脑拿走并在他们回来时再次合并（总共大约 6 台笔记本电脑通过 1 个服务器合并）。
该系统在最初设置时似乎很好，但在大约一个月过去后几乎停止，合并作业需要近 2 小时才能运行，每个用户，服务器没有任何挣扎。
如果我删除整个出版物并重新创建所有订阅，它似乎可以正常工作，直到大约再过一个月，然后我又回到了同样的问题。
该数据库设计不佳，缺少主键/索引等，但最大的表中只有大约 3000 行。
有谁知道为什么会发生这种情况，以及在删除和重新创建出版物时是否存在丢失数据的风险？
问题是 sql server 复制创建的元数据，有一个通宵作业清空并重新填充 3000 行表。这会导致复制每天复制所有这些行。
订阅设置为永不过期，这意味着旧的元数据永远不会被 sql server 删除。
我现在将订阅期设置为 7 天，希望它现在会在此期间之后清理元数据。我做了一些测试，证明如果订阅过期，更改不会丢失。但是服务器上的任何更新都优先于客户端。
I have encountered with "Waiting 60 second(s) before polling for further changes" recently in 2008 R2.
Replication monitor shows "In progress state" for replication but only step 1 (Initialization) and step 2 (Schema changes and bulk inserts) were performed. I was very puzzled why other steps do not executed?
The reason was simple - it seems that for merge replication demands tcp/ip (and or not sure) named pipes protocols activation.
No errors were reported.
Probably the similar problem (some sort of connection problem) became apparent in Ryan Stephens case.