Hi Jim,

Thanks for your insight. I think my understanding of reading records which are involved in a transaction agrees with yours. I have read a couple of published articles which say that other users cannot even read records which are part of another user's transaction, but I do not think that is true.

By the way, I just finished reading one of the best VFP 6 books available. Hentzenwerke Publishing publishes "Effective Techniques for Application Development with Visual FoxPro 6.0" by two great authors. I recommend it to every serious VFP developer. (I hope I am not breaking any rules by plugging your book, but it really was good.)

Sam

>Sam,
>
>First buffering is not what Walter has stated exactly. Buffering has always been part of Fox. The proof is that in Fox 2.x when editing fields directly the disk light did not flash with every keystroke of the user. That means that Fox was buffering the user's work and would write it to disk later. The problem was that we had no control over when or if that buffer would be written, it would and whenever fox was ready to do it.
>
>When we enable buffering in VFP we are getting control over the writing of the buffer to disk. We use TableUpdate() to write and TableRevert() to discard the buffered changes. As for locks, well if you enable pessimistic buffering every record is locked as soon as an edit begins. With optimisitc the records are not locked until you do the tableUpdate().
>
>Transactions are used to group a series of tabelupdates() into one all or none operation. If there is only one tableupdate then using a transaction is sort of redundant, as the arguments for tabelupdate can be used to make it an all or none operation.
>
>There is no lock short of exclusive use that prevents reading the tables by another station. That is unless you are using file server transactions like Novell provides. VFP trnasactions do not interfere with reading the data.
>
>A transaction shows it power when multiple tables need to be updated in a single operation, like saving an invoice. You need to update the invoice, invoice details, the AR, and the Customer tables. The problem you use a transaction to avoid is the situation wehre three of the four tables got updated but the last couldn't get done. So you use a transaction;
>
>

>LOCAL llRollBack
>BEGIN TRANSACTION
>IF TableUpdate(1,.f.,"Invoice")
>   IF TableUpdate(1,.f.,"InvDetail")
>      IF TableUpdate(1,.f.,"AR")
>         IF TableUpdate(1,.f.,"Customer")
>         ELSE
>            llRollBack = .t.
>         ENDIF
>      ELSE
>         llRollBack = .t.
>      ENDIF
>   ELSE
>      llRollBack = .t.
>   ENDIF
>ELSE
>   llRollBack = .t.
>ENDIF
>IF llRollBack
>   ROLLBACK
>   TableRevert(.T.,"Invoice")
>   TableRevert(.T.,"InvDetail")
>   TableRevert(.T.,"AR")
>   TableRevert(.T.,"Customer")
>ELSE
>   END TRANSACTION
>ENDIF
>