分布式环境中事务的控制,如果只是通过MIDAS并不能很好地解决。
建议采用MTS/COM+再加上MIDAS地结构模式,让MTS来处理事务,
COM+处理逻辑,MIDAS处理数据,ADO负责连接数据库。
这样可以解决这个问题,当然,编程难度也会增加。

解决方案 »

  1.   

    这种情况下如果有一个CLINE APPLY了,那其它客户端APPLY时会出错,自己根据出错信息处理是一种办法,上面说的用MTS也是一个办法
      

  2.   

    我不解,这跟事务有什么关系?只要是个错误就一定要 rollback, 难到还有发生的错又不 rollback 一说?用 MTS 又有什么用,结果还不是一样。我觉得这是数据是否要被更新的问题,可以用 TDataSetProvider 的 UpdateMode 来控制,又有几种可能,如果你很明白 ADO 的 Cursor Type,TDataSetProvider 提供的方式最接近于 ctStatic。1.当记录以第一个人修改的为准的时候,UpdateMode 设为 upWhereAll, 因为所有的 Field中ProviderFlag中为 pfInWhere的字段都被做为定位原始记录的条件。之后的人再修改这条记录会引发异常 'record changed by another user'
    2.当记录要以最后一个人修改的为准的时候, Updatemode 设为 upWhereKeyOnly, 因为只有Field中ProviderFlag中设为 pfInKey 的字段被做为定位原始记录的条件。只有当前一个人连Key值都改变的记录才会引发异常 'record changed by another user'
    3.最后一种就是 UpdateMode 设为 upWhereChanged 时的情况, 这种情况比较复杂,定位原始记录的条件为 Field的ProviderFlag包括 pfInWhere并且它的内容已经被修改的字段。这种情况可以认为是当第二个人改动的字段跟第一个人改动的完全不一样时,改动被承认,常常是种非常有效的选择,因为往往 upWhereAll 再过于强调第一个修改的用户有效,而 upWhereKeyOnly 又过于认可之后的用户的修改, 而 upWhereChanged 是个择中的选择,只要之后的用户修改的并不影响之前用户修改的值,就可以成功。明白了 DataSetProvider 中的 UpdateMode 后,就可以对多用户的情况进行控制了。
      

  3.   

    To comanche:
       这里有点不明白,比如同时有3个人要提交数据,实际情况应该是在第2个人提交后,第1个人再读出新数据,再提交,而现在是第1个人先于第2个人提交了,对于数据库来说,数据没有错。
    但这样实际的数据流程出错。
      这样的情况,好象不是是通过选择UpdateMode就可以解决的吧??
      还请指教。
      

  4.   

    可以设置TDataSetProvider 的 UpdateMode就可以了
      

  5.   

    To cobi
       在哪一部分???