用TClientDataSet做假三层,来代替二层好不好,现实不现实??

发现批处理的使用方式的确不如直接提交那么好.比普通的二层要多很多问题处理.
1.保存数据发生错误时,可能是几条,而不是一条.这样就要在列表中用不同的颜色显示出错的记录及提示出错的信息.
2.如果用户没有UPS,遇到一停电,数据就完了.普通的两层就没有这个缺点.
3.如果用两个TClientDataSet做成一主一从的数据表.使用就更麻烦了.主从表使用这样的批处理,会有更多的问题出现...非常非常麻烦.但我做这个控件的目的有一个,就是想把数据集读到内存之后,马上断开链接,象ADO.NET一样.呵呵.这样做,二层就可以并发更多的客户端.看来,只有在AfterPost和AfterDelete后马上ApplyUpdates才好处理.就象普通的二层一样.其实用这种方式
TAdoConnection->TDataSetProvider->TClientDataSet->TDataSource
代替普通的二层这种方式
TAdoConnection->TAdoQuery->TDataSource ,
现实不现实?各位说一下.

解决方案 »

  1.   

    你所说的问题三层有二层也有1) catch update 的问题, 没可能每改一个东东都立即更新 dbms, 这样效率得不到保障
    cds 你可以 ApplyUpdates(delta, maxerror), 成 maxerror 来决定出错的数量, 0 就是不许出错, 让客户改正后再提交
    双层也是同样的问题, 你不能每条去提交, 数据完整性得不到保证, 嗯...各方面原因啦, 数据库本身就没实时可言2) applyupdate 后的数据几层跟双层是同样的, 没什么区别, 在编译中的数据没了大家也都一样, 有何区别?3) 主从表双层是通过大量的反复查询实现的, 最后你会发现 cds 的主从表更理想, 无非是在 DataSetProvider 的 OnUpdateRecord 事件中做控制, 
    if SourceDS = 主表 then
      (Sender as TDataSetProvider).UpdateMode := upWhereChanged
    else if SourceDS = 子表
      (Sender as TDataSetProvider).UpdateMode := upWhereAll
    就是一般的作法了, 还可以进一步细控
    正确理解后再决定是否做组件吧..
      

  2.   

    一般做三层或用缓存不要“看来,只有在AfterPost和AfterDelete后马上ApplyUpdates才好处理.就象普通的二层一样”这样的三层没有什么意义
    如果怕突然掉电，可以采用公文包的技术，这样来电了可以借着停电前的工作继续
      

  3.   

    嗯.我已经做过测试,如果多个TClientDataSet使用同一个AdoQuery及DataSetProvider是有问题的.
    所以最好还是一个TClientDataSet对应一个DataSetProvider及一个AdoQuery.我的这个组件,TClientDataSetX从TClientDataSet中派生出来.自身还包含一个AdoQuery及DataSetProvider的子对象,所以并不需要象楼上写代码来判断是主表还是子表.这个TClientDataSetX放在窗体上就象二层的TAdoQuery放在窗体上一样,直接去使用.我也明白每次Post及Delete时都ApplyUpdate是不好.但是上面不是说过了吗?一个单表ApplyUpdate时如果多条记录出错时,错误处理比二层复杂得多.这种复杂,不但自己处理它很麻烦,而且使用户也觉得很麻烦.嗯..比如我在单表删除N条记录,但在ApplyUpdate时发现有一条删除不了(此表不允许级联删除).好了.用户就要UnDoLastChange来恢复被删除的记录.很晕.被删除的记录居然出现在最后一行,而不是原来的地方.......我也明白到象凭证一样主从表的数据完整性.就是添加一条凭证后,如果不按"SAVE",整条凭证就不应该进入到数据库中.但是有些主从表并不是这么严格要求的.我选择主项的一条,就可以在细项中添加数据.可能以后又要在细项中再添加一些.
    如果TCLIENTDATASET用于这样的主从表,它们也使用批处理的方式来保存.假如有时遇到细项的保存时遇到约束错,而不能保存.死了,都不知道如何显示这些错误的细项数据好.因为细项的数据在主项选择特定项才能显示出来..三层的主-细-细2 这样的表,就更更麻烦了...还有删除的问题.其实楼上只要细心一点,一样发现批处理方式存在着极大的麻烦...总之一句,批处理方式真是用得不爽.
      

  4.   

    我看是你用法问题, 这套体系还是很好的, 楼主应该用一下 BDE, ado 本身的特点就让程序员无法对一些操作细控, 这样反而还觉得是别人的问题了...再回头, 细看 ado, cursor type, lock type 等等就另有体会了"被删除的记录居然出现在最后一行,而不是原来的地方" 这样的话本身就有问题, 记录有顺序吗? 要有顺序应该按某一列排序, 这样你总是能出现在原来的地方Cds 的批更新,批出错方式是可选的, 但是是默认的, 你可以 ApplyUpdate(maxerror) 设为 0 就不是批出错了
      

  5.   

    嗯,楼上也有些道理.但我不可能用BDE吧.如果用BDE的话,给人家发布程序还要加个BDE,不麻烦才怪啰...我一般都用ACCESS,SQL 2K多.BDE比较ADO,有什么好处呢?
      

  6.   

    体系问题, bde 我认为是最值得看看的经典 cs, 里面不少先进思想, 并且 bde 兼容性是相当的好, bde 用于 3 层不合适是因为 session 有大限, 32 个, 而 cds 可以完全代替 bde 中所有先进思想, 而不理会连接用的引擎