Thanks Jim, but that leads to a few more quandries:

Mainly, *IF* " In truth, with data buffering the transaction does not start until you do the first tableupdate ", then what would it hurt to put the begin Transaction in the Init (or wherever it is best placed to convey the message)?

The Help is once again guilty of grave deficiency here, because it is not at all obvious that what you record here (and which I do not doubt for a minute) is so from the limited Help available.

Cheers,

Jim N

,>>Richard,
>>
>>I notice that you, like most others who use TRANSACTIONS, put the Transaction statement immediately before a TableUpdate.
>>
>>While it seems theres absolutely nothing wrong with that, I was just wondering why people don't put it in what to *me* would be a far more "logical" place - right in the code just before where the first applicable REPLACE or INSERT or DELETE is coded????
>>
>>Seeing some post-TableUpdate code checking the return value and issuing ROLLBACK or END TRANSACTION would still signal the usage of TRANSACTION. It seems to me that Begin TRANSACTION coded where the actual 'transaction' really starts just gives the reader fewer chance of surprise later in the code.
>>
>>Just curious
>>
>>Jim N
>
>Jim,
>
>The issue is that a transaction locks system resources on the network and you want to keep the begin and end as close to each other as is possible. In truth, with data buffering the transaction does not start until you do the first tableupdate. Also, most interfaces don't do replaces but rather are using data bound controls to allow the user to edit the data. Wrapping the entire edit session in a transaction would mean putting the begin in the Init of the form and the end in the unload. That would not be a very well behaved network neighbor.