Hi all, I've been reading this thread, and I'm worried, I ALWAYS use row buffering in my ISA (parent table), be it a single table form, or a one to many. Since I usually implement an edit mode (I just heard most people don't. but that's another discussion), record navigation is disabled until the user saves.

Doing this I see no need for using transactions in your regular one table form, it would apply for a one to many though. In general I use trabsactions when I need to update more than one table, and it's an all or nothing operation.

Now I hadn't thought of using table buffering and TableUpdate(.F.) to save the record, I suppose it would be the same, but why the need?, I try to keep my forms simple and with private data sessions, I don't see why the record pointer would move?, what are this commands with "unexpected" behavior you all talk about?, am I missing something?

>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