>>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
Hi Cetin,
No, I'm going by what I read in Jim Booth and Steve Sawyer's book in the chapter about Views, Chapter 5. Let me quote:
You will note the comment in this code that all views should be table buffered, even if you have only one record. This is because of the fact (discovered and documented by our able technical editor) that certain operations, contrary to expectation, will attempt to move the record pointer. If the view is row buffered, this will cause an automatic TableUpdate(), which is to be avoided at all costs.Now, if you were in this sitation, but wrapping any change to data on the form in a BEGIN/END TRANSATION, then you wouldn't have to worry about accidental record pointer movement. I realize that a Transaction locks users out of the affected records, so maybe this would only be good if you were already using Pessimistic buffering rather than Optimistic.
This is why I'm attempting to get some discussion here about this ... it's good to be armed with the Pros and Cons of various methods of doing things. There's always more than one way to skin a cat! < g >
-Bonnie
