>>in time responses

Do you mean performance..??? It's immaterial. And, if you need an all or nothing situation, it is a moot point, you NEED to use transactions..

>>
>>Not sure what the dynamic aspect is... I am not sure where the big complication exists here.. Transactions provide the ability to have all updates committed or rolled back. In other words, in the confines of a transaction, it is an all or nothing proposition - (the ACID principle...). While you may use buffering, unless you use transcations, you run the risk of having only part of your updates committed. Good examples include accounting-based apps. Both the debit and credit updates need to be committed. If one does not commit, the other should not...
>>
>>It is a fairly simple concept.......
>
>John,
>
>What is the impact ( if there is one) in time responses on a transaction? Would any be delayed?