>Hi Al,
>See responses inline...
>
>>If you're not doing it already, it's a good idea to apply the registry changes outlined at http://www.alaska-software.com/community/smb2.cxp to every workstation that accesses VFP data tables.
>
>--> I have never had data corruption problems but looking for the first time at what the registry changes are, they seem pretty innocuous so will give them a try
>
>>I see you list "VMWare" in "Virtual environment" in the message header. Is the server storing the VFP data tables virtualized, clustered or anything else unusual? Is it a true Windows server, a NAS, or ?
>
>--> the tables are on a virtual server in VMWare; no clustering (they are the old style free tables). It is a true Windows server (2012).
>
>>Are the Windows computers running your app actual physical computers, sessions on a Remote Desktop or other VDI backend, or anything else?
>
>--> the computers are real computers; the only people running off of RDC are those users who have had the problems; their RDC server is Win 2008 and by running the app on it, they avoid the problems (because I guess the architecture of Win 2008 is more like Win 7 where there was no problems).
>
>>You've also titled this thread "Data Lag". What does that mean - does freshly input data eventually show up after some period of time, or does it never show up unless you perform drastic actions to force a re-read of the data?
>
>--> if the user puts new data into a form (one parent record, one to dozens of child records - from one child table) and then saves and closes the form, and then reopens the form within a few minutes, the child records of that form do not show up. If the user then closes and reopens the form 2 or 3 times, the child records show up (they don't have to wait - just doing this over and over eventually gets them the child records).
>
>Update: Craig Bernston recommended issuing a FLUSH after saving out the records. Through testing (not production), it seems that this is effective if FLUSH...FORCE is used - FLUSH without the FORCE did not help. The help file says FORCE issues the command via an OS call so maybe this helps because the OS is also caching data?
>
>It was also interesting in that even if the user entered a brand new parent record with child records that the parent record always showed up. I think this is because an RLOCK() is done on the parent but not the children (because rightly or wrongly, I figure if the parent can be locked, the children probably do not need to be locked - as long as the parent is always locked first and then unlocked last when processing saves). In the FLUSH help docs, it says that issuing an UNLOCK "writes out to disk" implicitly (although I have not tested this - maybe the OS would still cache the data?).
>
>I will have to test some changes in production to see if the FLUSH...FORCE is the answer.

Here's an example of how one of the registry mods referred to in the Alaska Software link fixed a different issue: a folder refresh issue on Windows 7 (albeit against a Samba back end): http://serverfault.com/questions/482174/slow-shared-folder-refresh-on-windows-7 . It might be worth trying those mods before making a lot of changes to your code.

I think you mentioned in another thread that your app uses ProMatrix. Is it possible the framework is doing any tricks when saving or reading data to improve performance or for any other reason?

You also might want to ensure that no licensing limits are being reached or exceeded, either in the server VM or in certain hardware devices such as routers (Cisco etc.).