>Hi guys,
>
>I have some questions on the various ways that I've seen VFP Transaction processing handled. It seems to me, the "approved" method is to wrap the BEGIN/END TRANSACTION around the TableUpdate()s in the Save method of the form. OK, this works fine when you are using Table Buffering, but what about for Row Buffering? Sometimes the record pointer in a table is moved when you don't expect it to be (one of the dangers of using Row Buffering, IHMO), in which case your updates have been committed before you're even ready for them to be.
>


I don't know why anyone would EVER want to use Row buffering. I really can't think of a single situation. The reason is exactly as you have mentioned: It takes the process of TABLEUPDATE() out of your hands. There are several operations BROWSE, USE IN, etc, that cause the data to be written automatically. When is this EVER a good thing?


>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.