>>>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
Hi Bonnie,
I shouldn't get into this discussion because I don't use row buffering at all. I was caught with "row buffering" side effects in my very first app so from then on I use "table buffering" whether it's a parent or child (versus some suggestions). Transaction warning about that it causes records to be locked made me think if I were using "optimistic" buffering, then I should keep the transactions in small fast places where tableupdate should be done (typically save routine).
I can't get the idea how transaction + optimistic buffering be compatible with each other. With pessimistic it wouldn't be a problem and I could just begin the transaction at the load routine. How really would transaction accept the "involved records" to put automatic record locking is another obscure question for me.
OTOH I used transactions where I had to temporarily change a record's contents even if there was no buffering at all.
This reminded me an old section "implementing a database that would never broke" in Prolog user's guide. Yes, database was never broken no matter how often you power off :) But implementation to real apps was a nightmare.
I prefer to skin my cat in an optimistic way :)
Cetin
