Walter,

A comment you made attracted my attention. You said that sometimes other users can't even read data involved in a transaction. I have no experience with transactions, but I would like to understand that statement better.

A skeleton of a typical transaction sequence as I understand it would look something like this:

BEGIN TRANSACTION

TABLEUPDATE(...)

END TRANSACTION

I realize a lot of testing etc. is left out of this example, but for my purposes this will suffice. Assume we have modified 100 optimistically buffered records prior to executing this skeleton code. When the TABLEUPDATE() is executed, I think I understand correctly that first all 100 records get locked and then all 100 records get updated and then when the END TRANSACTION gets executed, the locks are all released. Now assume that during the time that the 100 records are locked and are in fact being updated, another user attempts to read some of those same records.

Now for your statement. Are you saying that sometimes other users cannot even read the original records while the locks are in place? Or are you saying that sometimes other users cannot lock the original records while the locks are in place and therefore they cannot see the modifications to the original records until the locks are released?

If other users cannot even read the original records which are involved in a transaction (I mean the unmodified version of those records), then I am very curious what kind of a lock FoxPro is using. Usually record locks and even file locks do not prohibit other users from reading records. The only way I know of to prohibit other users from even reading records is to open the file exclusively.

I must not understand transactions completely. Any further help would be appreciated.

Sam

>Russel,
>
>Buffering is used to access data without having record locks on the data while editing it and gives you the ability to undo your data changes with tablerevert().
>
>Transactions are used to get the "all or nothing" function. Everything between the BEGIN TRANSACTION AND END TRANSACTION does succeed or everything fails. The drawback of transaction is that the data gets lock (sometime you can't even read the data) to other users on the network while your in the middle of a transaction.
>
>By working with transaction it's wise to make the time a transaction lasts a short as possible thereby minimizing the conccurrency problems by other users on the network.
>
>regards,
>
>Walter