实现数据同步的正规做法是用SQL-Server的复制功能，但复制在这里显得有点小题大做。
从一开始在考虑客户端数据库时鉴于数据量的大小及客户端的其他需求，就决定为用MSDE，在每一个签到终端安装一个SQL-Server无疑是很浪费的。考虑到为了系统以后有更广的适用性，使用绑定数据库平台的技术也不是一种很好的选择。更为重要的是在系统中，数据同步压力并不是很大，情况也不复杂，需要动态更新的就一张表，就固定的那几列，并发冲突的策略也很简单，在可预见的时间内实现系统胜任的数据同步功能是可以做到的。最终实现的东西其实比我最开始设计的还要简单（因为客户有些功能不需要）。
跟数据同步有关的一共有三张表（不是二张），在DB Server与Local DB上各有一张总的签到明细表记录所有与会人员的与会情况，除此在外在Local DB上还有一张本机签到表，只记录在本机签到的人员。当然用二张表也能实现同样的功能，只要多加一些标志，但会繁烦很多，而且更易产生并发冲突。
现在所谓的数据同步分为二个过程，我称之为上传过程(简称U)与下拉过程(简称D)。
上传过程(U)：本机签到人员从Local DB上传到DB Server，此过程的意义是可以让管控端的签到监视与统计有依据，同时作为下拉过程的源头。具体过程见下图
过程主要是三步：
1、从Local DB获取目前还未上传的本机签到记录
2、如果有记录，据此更新DB Server上的签到明细表
3、如果更新成功，把这一批的本机签到记录上传标志置为“已上传”
下拉过程(D)：从DB Server的签到明细表中，拉取最近一段时间最新的签到记录，更新Local DB的签到明细表（Local DB的签到明细表要与DB Serve的保持一致的原因是因为要判断目前签到者是否为“首次”签到），具体过程见下图 
这个过程更简单，只有二步：
1、获取最近一段时间，其他签到终端的签到记录
2、如果有记录，据此更新Local DB上的签到明细
以上二个过程各自周而复始的在程序的后台运行。
注：
a) 什么是最近一段时间，在系统中为了区别哪些签到记录是上一周期已经获取过的，我用时间来作标志。在U2步，在每一条更新的记录上会记下当时的上传时间（更新是在DB Server的存储过程里进行的，各个签到终端时钟不一致不会有影响）。所谓最近一段时间，其实就是之前的下拉周期中所记录到的最大的上传时间点之后那一段时间。
b) 只获取其他签到终端的记录，这完全是为了减少一点数据的传送量，本机签到记录在Local DB上是同时记录在签到明细表与本机签到表二个地方的。
在系统中搞数据同步不是为了好玩，在前面的模块概述（上）我们知道，Local DB的存在与数据同步的出现完全是为了离线运行的需要，经过上面“三表二过程”的运作，现在基本满足了这个要求。接下来就是添加一个数据库连接监测的功能，如果DB Server无法连通，那么上述过程就可以在某步直接跳出（或是出现异常后跳出）。
数据库连接监测，本来想来个数据库可用性监测的，但在.net 1.1里IDbConnection接口的State属性形同鸡肋，所以只能监测它的连接是否正常（程序中图省事，只测试了机器的物理连接是否正常，以后要更正）。
最后为了客户端的显示需要，数据同步组件对外公布了几个事件，如数据库连接变化事件，签到人数变化事件等。与此同时开放了一些属性供外部设置，如同步的时间间隔，连接监测间隔等（因为系统对实时性要求只是一般般，所以开放设置让客户根据实际情况决定上述数值）。
理论上的问题：这样的同步过程存在着一个理论上的问题，即对于“首次”签到的判断。因为这个判断是建立在Local DB的签到明细表上的，而这个表在理论上讲并不是第一时间的签到明细表，如果同一签到者，在一个同步周期之内，在一个以上的地方签到，那么在每个地方，系统都是认为其为“首次”签到的。但在正常情况下，这只在理论上存在问题，原因是数据同步周期一般是很短的，也就几秒钟时间，而各个签到终端是分散在各处的，同一签到者不可能在一个周期之内光顾一个以上的签到终端。如果是在异常情况下，网络异常了，或DB Server无法正常工作了，那在此种拓扑之下，任何技术手段都无法解决“首次”签到的判断问题。所以这个理论上的问题也就不成为问题了。
更进一步：上面提到的数据同步只是动态数据的同步，系统中除此之还有静态数据的同步。因为表的数据量都不太大，用表拷贝就能基本解决问题。刚开始设计时，为了减少一些无谓的操作与流量，在DB Server上会记录一些表数据有变更的数据表，当签到终端启动时、或是管控端发出派发指令时（签到终端也可以发出请求指令），数据同步组件会去同步那些变更表的静态数据。因为静态同步这一块单元测试时没有如动态同步那么充分，后来在客户那里集成测试时发现一些程序的BUG，且某些次如果DB Server数据更新量较大时会增加签到终端的启动时间，客户就希望恢复到以前只在管控端派发、拷贝全部数据表数据的模式，那种模式有时会长时间锁定UI。不过反正这种动作只是在签到准备阶段进行，而且在管控端程序UI一、二分钟的锁定也可以接受的，那是他们熟悉的操作方式。最后就改成了他们要求的模式。不过个人来讲对一块当然不会很满意，以后如果有机会要完善它。