SyncFramework 2.1 更新 &删除似乎没有正确应用 [英] SyncFramework 2.1 updates & deletes do not seem to apply properly

问题描述

我正在使用 SyncOrchestrator 或专门使用 http://code.msdn.microsoft.com/windowsdesktop/Database-SyncSQL-Server-e97d1208 作为基础，稍作修改.据我所知，这意味着所有连接都是对等节点或节点.

I'm synchronizing SQL Server 2008 with ~6 SQL Server 2008 Express clients (everything R2 I believe), using the SyncOrchestrator or specifically using http://code.msdn.microsoft.com/windowsdesktop/Database-SyncSQL-Server-e97d1208 as a base with slight modifications. To my knowledge this means all connections are peers or nodes.

我有 2 个范围.一种是仅下载，另一种是仅上传.仅下载范围充斥着标识列，主要是因为我不知道有什么更好的，并且仍然无法将 Guids 作为客户端的 PK 引入.这并不重要，因为所有客户端都应该拥有大约 8 个左右表的精确副本，而这些机器不会以任何方式接触这些数据，只会读取它.

I have 2 scopes. One is download only and the other is upload only. The download only scope is ridden with identity columns primarily because I didn't know any better and still couldn't wrap my head around introducing Guids as the PK on the client side. It doesn't totally matter as all clients should have exact replicas of about 8 or so tables and these machines don't touch this data in any way, only read it.

仅上传范围使用 Guid，因为幸运的是我可以控制数据库的那部分，并且 10 个客户端都使用相同的身份种子无法正确同步回服务器.两个范围都使用带有批量插入和整个 9 码的默认配置，因此我在配置端不应该做任何事情来搞砸.

The upload only scope uses Guids as fortunately I can control that portion of the database and there would be no way 10 clients all using the same identity seed could sync back to the server properly. Both scopes use the default provisioning with bulk inserts and the whole 9 yards so there shouldn't be anything I'm doing on the provisioning end to screw this up.

我最初没有使用 PerformPostRestoreFixup 设置所有内容，并且初始数据库将与来自主机的插入语句手动同步.这似乎很好，但似乎从未应用任何更新或删除.您可以放心地忽略这一点(仅用于历史准确性并证明我的无能)，因为我随后使用 VS2010 数据库项目将数据库重建为仅模式 &同步.然后我使用了这里概述的步骤(http://social.microsoft.com/Forums/br/syncdevdiscussions/thread/9ac6d1a1-1565-4b82-a8d8-3d4a9ff5d07b)(同步、备份、恢复、调用 performpostrestorefixup、在 x 客户端上同步) 并且在我设置所有这些的开发箱上，我可以很好地看到更新和删除.当我将它部署到 x 客户端时，我没有看到我认为应该看到的数据库镜像.

I initially set everything up not using PerformPostRestoreFixup AND the initial database would be manually synchronized with insert statements from the host. This seemed fine but no updates or deletes seemed to ever be applied. You can safely ignore this (only used for historical accuracy and to prove my ineptness) as I then used VS2010 Database Projects to rebuild the database down to schema only & synchronized. I then used the steps outlined here (http://social.microsoft.com/Forums/br/syncdevdiscussions/thread/9ac6d1a1-1565-4b82-a8d8-3d4a9ff5d07b) (sync, backup, restore, call performpostrestorefixup, sync on x clients) and on my dev box where I'm setting all this up I could see updates and deletes just fine. Its when I deploy this to the x clients that I'm not seeing a mirror of the database as I think I should.

初始同步会报错并尝试再次同步所有记录.我相信这是意料之中的.在客户端上的 ApplyChangeFailed 事件期间，我将除 DbConflictType.ErrorsOccurred 以外的所有内容设置为 ApplyAction.RetryWithForceWrite.这可能是问题的根源，因为我最初认为应该这样做以强制将更改交给客户端.我希望服务器在这种情况下始终获胜，但在跟踪期间，我总是在批量插入/更新调用期间看到短语本地获胜".我可能在重新申请之前就看到了错误，但看起来很尴尬.

The initial sync will complain and try to synchronize all records again. I believe this is expected. During ApplyChangeFailed event on the client I set everything other than DbConflictType.ErrorsOccurred to ApplyAction.RetryWithForceWrite. This may be a source of problems as I initially thought this should be done to force the change down to the client. I want the server to always win in this scenario but during trace I always see the phrase "Local wins" during the bulk insert/update calls. It's possible I'm seeing the error before the re-apply happens but it's awkward to look at.

我似乎遇到的唯一问题是仅限下载范围.最初的客户端数据库现在大约有一个星期了，如果我使用 performpostrestorefixup 步骤，我不会像我认为应该的那样看到从现在到那时应用的任何更新.就好像 SyncFx 几乎更喜欢客户端的空白数据库来启动初始同步，然后所有更新似乎都适用，没有 ApplyChangesFailed 事件启动.

The only problem I seem to be having is with the download only scope. The initial client database is about a week old now and if I use the performpostrestorefixup steps I don't see any of the updates that have applied between now and then as I think I should. It's as if SyncFx almost prefers a blank database on the client side to kick off the initial sync then all the updates seem to apply just fine with no ApplyChangesFailed events kicking off.

如果有人以前看过这个或知道去哪里，我将不胜感激.我的大脑已经炸了，试图确定这是怎么回事.我最后的努力是将空白​​数据库部署到所有客户端并让它们开始同步.我在开发方面没有遇到任何问题，但我只能测试另一个客户端以了解它是否会做任何不同的事情.除此之外，除了继续进行手动同步之外，我不知道该怎么做，这会完全破坏这个目的.我认为 PerformPostRestoreFixup 会完全缓解这个问题，但无论有没有它，我似乎都遇到了同样的问题，或者我可能没有考虑到我需要做什么.

If anyone has seen this before or has a clue where to go I would greatly appreciate it. My brain has fried trying to determine what it is that's going on. My last ditch effort will be to deploy blank databases to all the clients and have them start the sync. I've had no issues with this on the dev side but I can only test one other client to know if that'll do anything different. Aside from that I don't know what to do other than to keep doing manual syncs which would defeat this purpose entirely. I thought PerformPostRestoreFixup would alleviate the issue entirely but I seem to be having the same problems with or without it or perhaps I'm not looking at what I need to be.

谢谢

推荐答案

我想报告并关闭包含我的发现的条目.

I wanted to report and close the entry with my findings.

当我部署之前配置的客户端数据库时，我经常会以以下日志的形式获得 ApplyChangeFailed 事件:

When I would deploy a previously configured client database, I'd often get ApplyChangeFailed events in the form of this log:

[05:30:41 PM] - ApplyChange 失败:表名:，阶段:ApplyingInserts，冲突类型:LocalInsertRemoteInsert，操作:RetryWithForceWrite"

"[05:30:41 PM] - ApplyChange Failed: TableName: , Stage: ApplyingInserts, ConflictType: LocalInsertRemoteInsert, Action: RetryWithForceWrite"

当它试图重新插入已经存在的数据时，我认为这是预期的结果.应该将其更改为 RetryWithForceWrite 期间的更新语句，但我发现数据未随发送的内容更新.

This is what I thought would be expected as it tried to reinsert the data that is already there. What this should've been changed to was an update statement during RetryWithForceWrite but I found the data was not updating with what was being sent down.

一旦我使用完全空白的数据库启动每个客户端并在本地进行配置，所有这些错误都消失了.就好像每个客户端都期望只有它设置的一些唯一 ID.我还使用 x64 版本与 x86 版本，这可能对结果有一定影响或没有影响.我希望我能确定到底发生了什么，但似乎有疑问时，只要有可能，从绝对零开始并让同步填充数据是您最安全的选择.

Once I started each client with a completely blank database and provisioned locally, all of these errors went away. It's as if every client expects some unique id only it sets. I'm also using x64 builds versus x86 which may have some or no bearing on the results. I wish I could determine what exactly happened but it seems that when in doubt, and whenever possible, starting from absolute zero and letting sync fill in the data is your safest option.

这篇关于SyncFramework 2.1 更新 &删除似乎没有正确应用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！