距离上篇博客似乎又过了一段日子了，这段日子应该算是挣扎着过来的，从寻找同步错误的过程到使用新的解决方案，总共花了近3个星期，我想自己有必要总结下这次的经历。
项目是使用C#+VS2008开发的，客户端数据存储采用SQL SERVER Compact Edtion 3.5,主要想应用在windows mobile 5.0操作系统及以上的手机。对于客户端和服务器端的数据同步，最初我们讨论了好几种方式，主要包括RDA，合并复制，webservice写XML文件或SQLCE。RDA使用起来虽然简单、灵活，但因为其没有冲突处理机制及跟踪增量更改于是被第一个放弃.webservice写XML文件或SQLCE，我们粗粗估算了下，除了要另外建表外，没有个几千行代码就搞不定的，这又背离了我们开速开发的宗旨。而且我们也无法保障使用webservice写XML的效率。因此我们选择了代码量少，配置繁琐的合并复制。
程序的开发用了大约一个月左右，模拟器上调试均OK，将serverTool公开到外网，但发布到手机上了才出现A request to send data to the computer running IIS has failed的错误，因为那时候正准备将开发的结果展示给领导看，但这个错误却是意料之外的，这个错误是指示数据连接超时，当然了数据连接超时的原因有很多，而查找这个原因的过程更是让人抓狂。起先还以为是网络连接超时造成的，遂将数据删除得只剩一条，但还是出现错误。于是将原因归咎到了IIS访问用户的权限，于是乎又将快照及复制及虚拟目录的权限均设置成最高。还是出错。最后将原因归到了合并复制的配置过程上了，于是重新配置了遍合并复制，还是这个错误。没辙了，中间还使用过RDA来进行数据同步，但到了手机上还是这个错误。后来一个同事将手机连接到家里的网络，随意地点了下程序，发现可以。于是终于发现错误的源头在CMWAP的代理上网方式上。
百度了下GPRS网络，发现中国移动提供了两种上网方式，一种是CMWAP的上网方式，采用10.0.0.172：80代理服务器，这种上网方式有些限制，首先，只有满足以下两个条件的应用才能在中国移动的cmwap接入方式下正常工作1、应用程序的网络请求基于http协议；2、应用程序支持http代理协议或wap网关协议。还有种是CMNET，这种方式没有任何限制，与我们普通的PC机上网一样，可以随意地访问各类型的网站，但这种方式的缺点是上网贼贵，在我们这边是20元50M每个月，超过了按3分/K算，如果没有超过还好说，假如超过了。。。假如一首歌是4M，那么额外的你就得支付4*30=120元，汗呀..看来不能强求我们的用户使用这种方式上网了。我们只能寻求另外的解决方案。
不知道有没有其他朋友使用合并复制成功地同步过数据，忘了加一个条件就是使用CMWAP上网方式。至少我失败了，在各大论坛发帖求助，及疯狂地向国内知名的windowmobile专家发送邮件，甚至我的同事还将问题翻译成英文发送给window mobile小组，但均得不到满意的答案，这里我也感觉到了windows mobile移动应用在国内实在是太少，或许是局限于国内的移动网络。
希望这篇文章能给同样遇到此问题的您带来一点帮助。好在我们现在寻找到了我们的替代方案，就是使用微软最近才推出的Sync Service，因为是使用WebService做代理中间层，因此CMWAP的限制解决了。以后的文章中会介绍关于这个框架的使用心得，感觉速度还可以接受，第一次同步时（包括表结构及）花了35s,普通的同步12～13s之间，当然，这个数据只是针对的，在不同的手机和网络条件下不一样，仅做参考。
ps:这么看似乎前面的合并复制的翻译白写了，其实不然，因为我们的同步方案并不一定使用移动的网络，比如说桌面应用程序，具体还是要看应用了。
项目是使用C#+VS2008开发的，客户端数据存储采用SQL SERVER Compact Edtion 3.5,主要想应用在windows mobile 5.0操作系统及以上的手机。对于客户端和服务器端的数据同步，最初我们讨论了好几种方式，主要包括RDA，合并复制，webservice写XML文件或SQLCE。RDA使用起来虽然简单、灵活，但因为其没有冲突处理机制及跟踪增量更改于是被第一个放弃.webservice写XML文件或SQLCE，我们粗粗估算了下，除了要另外建表外，没有个几千行代码就搞不定的，这又背离了我们开速开发的宗旨。而且我们也无法保障使用webservice写XML的效率。因此我们选择了代码量少，配置繁琐的合并复制。
程序的开发用了大约一个月左右，模拟器上调试均OK，将serverTool公开到外网，但发布到手机上了才出现A request to send data to the computer running IIS has failed的错误，因为那时候正准备将开发的结果展示给领导看，但这个错误却是意料之外的，这个错误是指示数据连接超时，当然了数据连接超时的原因有很多，而查找这个原因的过程更是让人抓狂。起先还以为是网络连接超时造成的，遂将数据删除得只剩一条，但还是出现错误。于是将原因归咎到了IIS访问用户的权限，于是乎又将快照及复制及虚拟目录的权限均设置成最高。还是出错。最后将原因归到了合并复制的配置过程上了，于是重新配置了遍合并复制，还是这个错误。没辙了，中间还使用过RDA来进行数据同步，但到了手机上还是这个错误。后来一个同事将手机连接到家里的网络，随意地点了下程序，发现可以。于是终于发现错误的源头在CMWAP的代理上网方式上。
百度了下GPRS网络，发现中国移动提供了两种上网方式，一种是CMWAP的上网方式，采用10.0.0.172：80代理服务器，这种上网方式有些限制，首先，只有满足以下两个条件的应用才能在中国移动的cmwap接入方式下正常工作1、应用程序的网络请求基于http协议；2、应用程序支持http代理协议或wap网关协议。还有种是CMNET，这种方式没有任何限制，与我们普通的PC机上网一样，可以随意地访问各类型的网站，但这种方式的缺点是上网贼贵，在我们这边是20元50M每个月，超过了按3分/K算，如果没有超过还好说，假如超过了。。。假如一首歌是4M，那么额外的你就得支付4*30=120元，汗呀..看来不能强求我们的用户使用这种方式上网了。我们只能寻求另外的解决方案。
不知道有没有其他朋友使用合并复制成功地同步过数据，忘了加一个条件就是使用CMWAP上网方式。至少我失败了，在各大论坛发帖求助，及疯狂地向国内知名的windowmobile专家发送邮件，甚至我的同事还将问题翻译成英文发送给window mobile小组，但均得不到满意的答案，这里我也感觉到了windows mobile移动应用在国内实在是太少，或许是局限于国内的移动网络。
希望这篇文章能给同样遇到此问题的您带来一点帮助。好在我们现在寻找到了我们的替代方案，就是使用微软最近才推出的Sync Service，因为是使用WebService做代理中间层，因此CMWAP的限制解决了。以后的文章中会介绍关于这个框架的使用心得，感觉速度还可以接受，第一次同步时（包括表结构及）花了35s,普通的同步12～13s之间，当然，这个数据只是针对的，在不同的手机和网络条件下不一样，仅做参考。
ps:这么看似乎前面的合并复制的翻译白写了，其实不然，因为我们的同步方案并不一定使用移动的网络，比如说桌面应用程序，具体还是要看应用了。
