Hi!

VFP maintains internal buffers in memory for performance purposes. There are a bunch of records for each opened table in tehse buffers. As you do scan, VFP loads next bunch of records only when you get to next record that is not in the buffer. To see results of changes by anotehr user immediately, you require to have some way to refresh these buffers for each record. The performance with such refresh will be much worse because constant reading from the disk into buffer, so I do not recommend to use such approach. Just disallow 2 users to perform scan simultaneously, that will save you from many other side-effect problems, like corruptions and locks.

When you suggest to use this anyway, below are hints on buffers refreshing.

You can use SET REFRESH command to define the refresh time internal for VFP for automatic refresh. But this is good for browsing records and not for processing (when changes should be visible immediately).

To refresh record immediately, just attempt to lock it, that will read latest information from disk. You can also use sys(1104) function that also drop and re-read all internal buffers mentioned here.

Use also sys() function to set up the appropriate buffer length - make it as long in bytes as a size of a single record in table in bytes (talking about the table you use in SCAN command). This will prevent from extra readin from disk to fill extra space in buffer by other records than only one (current) record.

Hope this helps.

>I have a small app., based on a form & a single table (25 records). Originally designed for single user use, I'm now looking at modifying for multiuser use. Due to network problems, I am currently running 2 copies of the app. on a single PC (Win98).
>
>The problem I have come across relates to using scan ... endscan to keep the 2 applications in sync. What I have found is that if the table is updated by one instance of the app (using record locking & flush), when the second instance does a scan ... endscan, the updates aren't seen, unless I do 'go top' prior to the scan.
>
>Browsing from Foxpro, I can see the updates are done & the table updated by the first instance.
>
>Is this known &/or expected behaviour from scan ... endscan ? Nothing I can see in the docs suggests I need to do a go top prior to the scan. This happens both with & without the NOOPTIMIZE option.