我们有一个应用程序将使用Microsoft SQL Server Compact收集数据并将其存储在本地WinXP PC中。我们希望将这些数据汇总到一个完整的SQL Server进行报告和归档。数据传输需要相当连续（即不进行批处理），尽管某些延迟是可接受的（最多一分钟或两分钟）。
数据是从收集器到服务器的单向推送。收集器永远不需要知道其他收集器正在做什么，主服务器将永远不会更新收集器上的数据。目前的计划是针对5个收集器，但它在可扩展性方面基本上没有限制。
我们必须假设我们“大部分都是连接”但我们无法保证从收集器到服务器的连接。如果服务器或网络出现故障，我们仍然会收集，并且当服务器再次可以访问时，数据将被推回。
理想情况下，我们想要一个非编程工程师在完成基础设施工作后可以设置的解决方案。所以我们编写一些代码和向导很好，但最终用户不能被认为对编写代码有任何了解，尽管他们将拥有合理的技术计算机知识。
目前我们有两个技术候选人：
我们对第一个没什么经验，但是我们知道在SQL Server中设置订阅等很麻烦，调试它们并不好玩，所以我们试图寻找替代方案。
我们几乎不知道＃2，只是它被建议作为将设备数据提供给服务器的替代方案。
有没有人有这种情景或使用这两种技术中的一种/两种的经验，或者我们没有想到的任何可以分享的东西？收集器上的SQL Compact是固定要求。服务器上的SQL Server不是必需的，但是因为客户已经拥有它，所以需要它。
答案 0 :(得分：1)
我在完全发布之前使用过Microsoft Sync Services。我喜欢它，它似乎非常适合您的应用。
我建议，如果您想让自己轻松生活，可以使用GUID（SQL Server uniqueidentifier）作为要同步到主服务器的所有表的主键。这样可以防止冲突和大量额外编码。
一个警告：我听说Sync Services在第一个版本发布后发生了重大变化，所以我的信息可能已经过时了。
答案 1 :(得分：0)
尝试同步并告诉我们它是怎么回事:) 我看到了一个MSFT活动，这个人说：“我添加了这3行代码，所有内容只是同步... wooohhooo”。
听起来像是去找我的方式。
答案 2 :(得分：0)
复制的问题在于，当您的架构发生更改时，您将在每个客户端上执行手动工作以再次启动并运行复制。我没有使用Sync Services的经验，但我会问同样的问题：架构发生变化时会发生什么？如果你必须触摸每个客户，这可能是一个问题。
答案 3 :(得分：0)
我最终选择了选项3：两者都没有。相反，我们只是定期（用户可调，但默认为5秒）使用SqlBulkCopy class来复制记录。这很好用，因为它允许我们传入一个IDataReader，所以我们使用TableDirect在本地打开表，从远程表中寻找最高的RowID，然后将读者传递给WriteToServer类。