>>I have come across a very strange case with a customer where 2 users are using the same application (I verified by version number), looking in the same folder for the data. But one user sees fewer records in one table than the other user. I even connected to both of their desktops and opened the table via VFP9 (Command prompt). And I find different number of records in the table. And according to the user some entries are different.
>>
>>How can it be that when looking at the same table from two different computers the number of records and the content of some records is different?
>>
>>I ran FoxFix agains the table but didn't find any problems with this table.
>>
>>I would appreciate any suggestions.
>
>This get weirder and weirder. I connect to the customer (via GoToMeeting). Then from one computer I USE the table (in VFP9 Command window) in question and DISPLAY STATUS and NET USE. And then I do the same from another computer. Both computers see the file in the same place, folder mapped to the same network drive. I even zipped all data files from one computer and I see this .zip file from another computer. And then I zipped all data files from the 2nd computer. And I sent both of these .zip files to my FTP. I copied them to my computer (in two different folders). And indeed, one folder has this table to more records than the other. I reindexed, of course.
>Weird.

I like Greg's idea of USEing EXCLUSIVE or FLOCK()ing to see if both instances of VFP on separate computers are opening the same file. This would also help to rule out if a 3rd computer also has the file opened EXCLUSIVE and/or locked, and could be doing something that affects data buffering/cache coherency etc. The ONLY way one can be sure one is reading current data from a shared table is by obtaining an FLOCK() or EXCLUSIVE use.

I'd look very closely at the server hosting the data files. Years ago I ran into what I called "versioning" issues when working with VFP source files hosted on an older version of Samba on a FreeBSD server. Occasionally I'd find source files had seemingly "reverted" back to something 6 months or a year old, for no apparent reason. I got the feeling it was happening (or happening more often) when I'd save a file to the same name, but use different casing e.g. I opened a source file MYSOURCE.PRG but saved it as MySource.prg (which would be treated as 2 different files in the same folder in a native file system on *n?x/BSD, since those file systems are case-sensitive by default). It seemed that eventually Samba or my local machine would reconcile the file names and dates but in the meantime there was weirdness going on for sure.

If you're 100% sure it's a properly configured, genuine Windows server hosting the data tables, you might want to ask the admin if they're doing anything like running backups while you're testing or using any sort of 3rd-party "continuous data protection" product. Some such products use Volume Shadow Copy Service (VSS) which takes a snapshot of a volume, then deltas changes while a backup progresses. I haven't heard of or encountered any cases where users would get different versions of a table during a backup but I suppose it's theoretically possible.

Another thing to look at is the "computers" you're connecting to via NetMeeting. Are they real, physical Windows PCs, or are they Remote Desktop sessions on a Terminal Server, or even virtual machines or virtual desktops? In any of the latter cases there could be caching/optimization going on.

Another question about those computers: Is it possible they are in 2 geographically separated offices that are connected via something like BranchCache? If so and the table is not synced between locations it's possible one computer could see a stale version of the file, and the other the current version. Some further info about this at https://pertorben.wordpress.com/2012/05/29/dfs-r-or-branchcache/ .