Hi Erik,

Your answer about BEGIN TRANSACTIONs locking all underlying records (in addition to your discussion with John in another topic about using TRANSACTIONs similar to the way I have been mentioning) got me thinking about this again and I have another question ... does this "underlying record-locking" occur when you are using views to access the data or is it only when accessing the data directly. Perhaps I don't understand the exact mechanism of the way views actually work, but I was under the impression that the BEGIN TRANSACTION would only affect the view and not the tables that the view is based on. Am I way off base on this concept?

TIA,
-Bonnie


>>What I haven't heard mentioned much at all is to use BEGIN TRANSACTION as soon as a change to any data on the form is detected. Then, when the user Saves, Cancels or Closes the form you can do either your END TRANSACTION or your ROLLBACK.
>
>This is a really bad idea. A BEGIN TRANSACTION locks all underlying records for the duration of the transaction. So holding a transaction open during a use rwait state will cause nightmarish contention problems. Besides, that's not what they are for. This strategy is attempting to use transactions in place of buffering.
>
>>In utilizing Transaction processing this way, it does away with the problem of accidentally committing changes to a table in a Row Buffering situation.
>
>A better idea is to do away with this problem by doing away with row buffering.