I'm a firm believer in FLUSH.

I see nothing wrong with your code other than I would put the FLUSH just "before" the UNLOCK (and not after); FLUSH does a syncronous write, while UNLOCK does an implicit asyncronous flush, which would allow for a very small window for uncommitted data between your current UNLOCK and FLUSH.

And keep the "locks": this insures that a TRANSACTION is even worth "starting", and won't simply fail because it couldn't grab the necessary lock(s) further into the transaction.

Locks also keep the "context" of the transaction from changing: someone "updating" records that you are only "reading" within the context of your transaction will not cause your transaction to fail, even though "logically" it should have.

>From time to time I see references to similar problems regarding data not being written to disk or VFP working on stale information. I do the following:
>
>Set record locks
>Set the buffering for several tables to optimisitic table buffering.
>Make changes to the tables.
>BEGIN TRANSACTION
>TABLEUPDATE
>END TRANSACTION or ROLLBACK
>UNLOCK IN for all tables
>Turn off buffering
>
>VFP cannot find the changed data. However if I add a FLUSH immediately after turning off buffering, VFP finds the changed data. I am using VFP 8.0 on Windows XP Pro workstation, no network involved, and yes write caching is turned off.
>
>Is using FLUSH to make sure VFP gets the latest data reliable, or is there something sort of a window during which one cannot be sure which version of data is available? Some of these changes are fairly large, so checking each updated item against OldValue would be extremely tedious.
>
>Thanks in advance,
>David