本地数据库表的数据改变时服务器数据库对应的表也同时也改变
但是本地的联网状态不能确定时间，
联网时候 就把本地改变过的数据 添加到服务器数据库中。
请问 大虾们有什么好的方法啊！最好有代码··
我目前就 是用的 XML文件 读取数据 然后传到服务器，在进行读取但是发现这样做起来很麻烦
但是本地的联网状态不能确定时间，
联网时候 就把本地改变过的数据 添加到服务器数据库中。
请问 大虾们有什么好的方法啊！最好有代码··
我目前就 是用的 XML文件 读取数据 然后传到服务器，在进行读取但是发现这样做起来很麻烦
1.初始化本地和服务器的数据库,使其同步.
如backup --> restore
2.本地写个存储过程,做成Job定时执行.
2.1 判断本地的联网状态,如不通则退出. exec master..xp_cmdshell 'ping [服务器IP地址]' 2.2 如果是连网状态,将本地数据做差异备份. backup database xxx to disk='\\服务器名\共享文件夹\xxx.bak' with DIFFERENTIAL3.服务器写个存储过程,做成Job定时执行.
定期判断共享文件夹里是否有未还原的bak文件,如有则进行restore. restore database xxx from disk='[共享文件夹]\xxx.bak' with norecovery
不熟的话建议楼主先了解一下复制的原理.
例如本地表建复制(replication)到服务器上的表,
初始化快照后,数据是同步的.后面每次同步数据,将本地表的变更日志(Log)传到服务器上的表去重做,
以达到同步的目的.
所以如果复制监视器有报错也是正常的,不影响实际数据的同步.
但为了完善,可以在本地数据库的作业(Job)列表中找到同步对应的Job,
在执行之前增加一个步骤判断当前网络状态,
如果不通则直接退出,不执行同步以免报错.
2 因为网络因素不确定,建议订阅用请求订阅(pull)方式
1.不能用合并复制吧?
因为服务器端(S)也接收其他本地数据库(如C2)的Log,
合并的话要将这些也同步回其他本地库(如C1)吗?楼主似乎没这个需求.
我认为应该是各本地数据库对服务器做交易复制.
2.请求订阅就能避免复制监视器不报错吗?
请求订阅也跟网络有关系的呀,如果网络不通,总有一端会报错D.
2 之所以采用pull的方式,我不是说避免出错不出错的问题,而是楼主已经交代了网络环境不确定,也就是说可能随时是断网的情况下 另外也说了有不只一个本地服务器.我们来看看微软对请求订阅(pull)和推送订阅(push)的主要描述,我就不解释了
推送订阅:
* 通常，数据将连续同步或按照经常重复执行的计划同步。
* 发布要求数据近似实时地移动。
* 分发服务器上较高的处理器开销不会影响性能。
* 通常与快照和事务复制一起使用。
请求订阅
# 数据通常按需或按计划同步，而非连续同步。
# 发布具有大量订阅服务器，并且/或在分发服务器上运行所有代理会消耗大量资源。
# 订阅服务器是自主的、断开连接的和/或移动的。 订阅服务器将确定连接和同步更改的时间。
# 通常与合并复制一起使用。
大虾们给了我很多好的建议！我用的是 sqlserver 2008
由于 本地机器 很多，再说地方也不一样，如果要一个一个的去复制过来的话！估计是个问题。
所以我才会想到 这个方法，由于小弟 技术有限，没能做出好的方法来，
就想到 用xML 文件来传递数据，例子已经做出来了！
但是遇到了 很多问题，
就像 上面 你们提到的，网络终断，
还有一个问题就是 如果他们同时或某些提交的话，
数据就会 出现覆盖情况！
所以现在很愁···
这 楼 有什么好的方法嘛！
你的意思是 XML 可以还是不可以！
大数据量传送时,读取XML文件会很耗磁盘I/O的,所以不建议用.
我在把主要功能 说一下， 我用的是 asp.net 和 sqlserver 2008.本地服务器 向 网络服务器 提交新的数据，
1.要求每次提交的数据只需要 本地新的数据，
2.本地服务器 联网 状态不确定，
3，本地服务器 在100台左右，
4，本地服务器 上传的数据量，目前不确定。因为 2 ！
目前就是这些··
这是系统分析时的问题,不是SQL Server复制的问题了.
建议先把系统规则确认清楚,确保不会冲突和重复数据了,再来配置复制.
复制和XML,说到底只是数据库工具而已.前端程序设计也很重要.