>Hi Jim,
>
>>I'll bet most of us were leery of buffering, and especially OPTIMISTIC, when we first started with VFP, especially those coming from FPx.
>>And I'm of the opinion (still) that trying to code to "fix" a field update collision "on the fly" cannot really successfully and SATISFACTORILY be done. Sure, it *can* be done for the simpler stuff without harm but even there is it really reasonable to change ANYTHING on someone once the application has signalled "GOT IT" and implying don't worry about that anymore.
>
>So, Jim, does that mean you're for Pessimistic buffering? Do you use it in your apps?

Yes. Yes.

>
>>And, PERSONALLY, I'd like to be able to read code and learn EARLY in my reading, definitely NOT at the very end of a process, that a transaction is involved. In other words I'd really like to see a BEGIN TRANSACTION at the logical start of the transaction in the code, not at TableUpdate time. To me that should be possible, but it ain't that way so I'm stuck with it.
>
>It is if you do it the way I described ... issuing the BEGIN TRANSACTION as soon as any data on the form changes.
>
You're right. I've yet to write anything with transactions and so still worry that an actual implementation with pessimistic might be problematic.

>>>Not a problem if there are not many simultaneous users, and besides, the decision had already been made to use pessimistic buffering anyway.
>>>
>>Well, it could still be a very real problem, couldn't it. . . what if someone goes to lunch in edit mode, deliberately expecting to "hold" the record until they return?... or to a rush meeting?... or a mad rush to the john?...or has to look something up in some not-handy reference... or ...?
>
>Yes, a conscious decision has to be made when deciding to use pessimistic buffering with just such considerations in mind.
>
>>I do agree with the prevailing opinion that row buffering is to be avoided as much as possible. We *might* have had a fighting chance if the documentation indicated whenever a command does or doesn't move the record pointer. It might also have served to show the VFP design team where they needed to tighten things up to make row buffering more practical.
>
>OK, Jim, so which method do you regularly use?
>
JimB pointed out long ago that Table buffering can be used for single record updating too, so that's my general approach.

Cheers,

Jim N


>-Bonnie