Hi Dragan,

No, I wouldn't say it is any clearer (in fact it is nearly identical!).

The 'issue' here seems to be. . . DOES Begin Transaction start setting locks immediately *or* do locks actually only get set ONCE A RECORD IS ACTUALLY MODIFIED????

I understand that people feel that delaying the Begin Transaction until immediately before the TableUpdate assures that one does *not* need the answer to this question, but I see two problems with that:

1) In my personal opinion, it is decidedly not 'natural'. To me it is much more natural to place the Begin Transaction exactly where in the code one intends the "transaction" to begin;
2) The VFP folks 'could' some day change the mechanism so that it *HAS* to be coded in the more 'natural' way. They may, for instance, change the internals to only start 'tracking' records once the Begin Transaction is issued. In such a case the present practise would 'break'. Who knows?!@#@!

Cheers,

Jim N

>>Thanks Jim, but that leads to a few more quandries:
>>
>>Mainly, *IF* " In truth, with data buffering the transaction does not start until you do the first tableupdate ", then what would it hurt to put the begin Transaction in the Init (or wherever it is best placed to convey the message)?
>>
>>The Help is once again guilty of grave deficiency here, because it is not at all obvious that what you record here (and which I do not doubt for a minute) is so from the limited Help available.
>>
>>Cheers,
>>
>>Jim N
>
>Well, here's some from FPD2.6 help (though I seem to remember it existed in 2.0), about doing transactions using Netware.plb, and you decide for yourself if it's more clear and straightforward than VFP help:
>
> Record Access Considerations
> When you modify records in a database that is part of
> a transaction, other users on the network will not
> have access (read or write) to the records until you
> end the transaction.
>
> When other users on the network try to access records
> you have modified, they must wait until you end your
> transaction. They receive the message "Record not
> available ... please wait" until the records become
> available. Because of this, it is important to keep
> the length of the transaction to a minimum. It is
> best to end a transaction before you go to lunch.
>