>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.
>
>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. In utilizing Transaction processing this way, it does away with the problem of accidentally committing changes to a table in a Row Buffering situation.
>
>Can we get a discussion going on the Pros and Cons of both methods and any other alternative methods that others might have come up with?
>
> -Bonnie
Bonnie,
Then you're assuming you'd have hints on differentiating a true rec pointer movement from an accidental one. I would prefer using the hint and prevent accidental movements. IMHO record pointer never should move by accident. If you have to for any reason, you could save premove state, rlock, move, come back and restore. Restored data would be in buffered state.
Cetin
