但由于要允许用户切换操作不同的窗体,当这个窗体执行编辑操作时将数据库事务置于开始事务的状态,用户如果切换到了另一个窗体要进行编辑,那这个窗体又请发出了请求开始事务,这样肯定会产生冲突。。。。。
如果使用多个数据库连接必定会浪费太多的资源
如果不使用绑定到Grid的操作那么在保存时,这个Grid的删除、添加、修改数据的业务必又该如何实现呢?疑惑,不解。。。。。
11 个解决方案
#1
用clientDataset应该可以满足你的要求。所有的修改都是暂时保存在内存中。直到提交所有修改到数据库才开事务,如果保存错误,则回滚所有操作。
#2
不知道怎么用,请问一下如何用
#3
用PageControl也行吧,搞得事务控制那么烦琐!
#4
PageControl??????
#5
用缓存更新模式,修改不进入事务,只有提交时才进入事务。那样时间很短不会冲突
#6
请问如何设置为缓存更新模式
#7
设置locktype=ltBatchOptimistic(ADO)
#8
把DATASET的LOCK TYPE设成ltBatchOptimistic,用ADODataSet1.UpdateBatch(0);
ADODataSet1.CancelUpdates来更新取消更改,参看徐新华的书
ADODataSet1.CancelUpdates来更新取消更改,参看徐新华的书
#9
那就是说不用调用AdoConnection.BeginTrans来使用事务了
#10
因为这样一来是集中更新,只在数据保存的时候调用UpdateBatch就好了,除了考虑保存过程中出错就没有必要再使用事务了
#11
顶!
#1
用clientDataset应该可以满足你的要求。所有的修改都是暂时保存在内存中。直到提交所有修改到数据库才开事务,如果保存错误,则回滚所有操作。
#2
不知道怎么用,请问一下如何用
#3
用PageControl也行吧,搞得事务控制那么烦琐!
#4
PageControl??????
#5
用缓存更新模式,修改不进入事务,只有提交时才进入事务。那样时间很短不会冲突
#6
请问如何设置为缓存更新模式
#7
设置locktype=ltBatchOptimistic(ADO)
#8
把DATASET的LOCK TYPE设成ltBatchOptimistic,用ADODataSet1.UpdateBatch(0);
ADODataSet1.CancelUpdates来更新取消更改,参看徐新华的书
ADODataSet1.CancelUpdates来更新取消更改,参看徐新华的书
#9
那就是说不用调用AdoConnection.BeginTrans来使用事务了
#10
因为这样一来是集中更新,只在数据保存的时候调用UpdateBatch就好了,除了考虑保存过程中出错就没有必要再使用事务了
#11
顶!