Yau,

Thanks for the further explanation of what you are seeing it helps a lot.

If you have table buffering enabled you can not run a SQL command, because it looks to the original table and will not see the changes pending in the buffer. Xbase commands like scan will see the pending changes in buffer.

You will have to issue a TableUpdate() before the changes will be reflected in the table itself and then visible to other forms in your current app, and visible to other users on the network. It's also possible that you are having double buffering going on, buffering on the view and on the table, in which case TableUpdate() will have to be issued on both the view and then the table.

>Just to clarify a bit more about my problem.
>My app (VFP6SP5) has data entry forms using private data sessions, local views and table buffering for data entry.
>Tables are opened in the dataenvironment of each form. Due to slow screen startup, I've added an invisible form that has its datasession set to default that opens certain frequently used tables upon application startup and this form is not closed until application shutdown. It has worked well to improve screen startup times (transaction screens) from 20 seconds to 5-6 seconds.
>The problem is this. When 2 users enter transactions at the same time, data entered by the 1st user can be seen (through a click of a search button that pops up a separate form using default data session that does a sql query to retrieve records from the base table of the transaction file) by the second user, however, once the document number is retrieved by this search screen to the transaction screen, the new record cannot be retrived by the transaction screen of the second user. In short, the transaction can be seen but not retrieved!
>I've tried flush, moving the record pointer via locate and go bottom plus a skip but still can't get this fixed.
>Only way it work was using an flock() which to me is rather draconian given that the app is run by more than 30 users at one time and takes a severe performance hit.
>Opening and closing of the table again is out of the question for the same reason as flock().