沖突發生後,在Enterprice manager里邊有一個工具(不記得叫什麼了,我電腦上現在沒環境),可以讓你處理每一筆沖突的資料,讓你保留任意一方的資料(其它方的資料會被SQL Server殺掉)。
我就知道這麼多~~~呵呵。

解决方案 »

  1.   

    謝謝,這個我了解
    我想知道如何根据具体情況自動确定保留那一方的操作
    比如寫一些SQL語句來判定.而不是簡單的根据优先級別判定.
      

  2.   

    好像沒辦法。
    關於MSSQL 的Replicate沖突問題,我們公司請教過很多次微軟工程師,那些家伙每次都是嘰嘰歪歪的說一大通,到頭來還不是要手工解決問題。 有一次一個客戶的資料有兩萬多筆發生了沖突,可憐我的mouse硬是活生生的點了兩萬多次。~~~:(
      

  3.   

    難道就沒有一個比較爽的解決之道?
    另外各位DBA,是否有利用慢速INTERNET連接+WISDOWS VPN撥號 作數据合并复制的經驗? 
      

  4.   

    放了好几天了,哪位還有高論?
    或者有不用MSSQL REPLICATION的思路也可以,只要能有效實現.
    周4結帳!
      

  5.   

    同步数据有几种方式。看起来,你使用的是“合并发布”方式。也就是说,你的订阅服务器
    和发布服务器都可能会对数据进行修改、插入、删除操作。尔后,在规定的时间同步数据。
    当更新在各站点(服务器)之间传播的时候,即发生同步处理。数据库的合并代理程序
    (replmerg.exe)将所有更改过的数据发送到其他站点。数据从更改发生处流向需要更新
    或同步处理的站点。
    冲突发生在,当目的数据库合并从其他数据库传播来的更新与现有值之时。合并代理程序
    评估送来的值和当前值,而新旧值之间的任何冲突由默认的程序自动解决。可在创建发布
    或自定义解决程序时指定此解决程序。
      

  6.   

    使用Replication的代价是昂贵的。尤其是“合并发布”方式。
    建议采用MSMQ、COM+解决分布式数据库应用。
    COM+包含DTC(分布事务协调器)服务,相当于BEA的中间件Tuxedo。可以支持“two phase commit”(两阶段提交)。两阶段提交就是为了保证各服务器之间的数据一致性。
    而MSMQ支持异步,如此,便能解决远程网络调用问题。
      

  7.   

    我目前所知道的只有一個priority可以控制,自定意解決程序如何操作?