Al, thanks so much for the link from Alaska software. If you or someone might have some info/advice on this question, it would be helpful. In reading Alaska info on their install patch to the Registry, it sounds like they are setting these 3 items within:

HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\LanmanWorkstation\Parameters

and create and set these to 0:

 FileInfoCacheLifetime
 FileNotFoundCacheLifetime
 DirectoryCacheLifetime

Using Codemine framework with VFP 9, I can easily do this on the fly. My question (general advice) would be would this be a good idea on my part, or should I require my user's to go through Alaska to get this, or I do it through code.

I ask this in case there is something in the Alaska install that I am not aware of.

Or are there any other registry settings I should be aware of that pertains to this issue.

Any advice is appreciated.


>>I suspect this topic has been dealt with before. Can someone give me some links and general advice on when Microsoft Windows changed a setting which has the potential to cause data loss and how to correct this before it happens using latest release of VFP 9. I believe it is a regedit setting.
>>
>>I am hoping there is an install package I can include that will take care of this.
>>
>>Thanks in advance....
>
>Thomas' main point is well taken. However, if you need to use native VFP data tables on modern Windows networks, the generally accepted best practice is to set some registry values on "workstations" per http://www.alaska-software.com/community/smb2.cxp .
>
>A "workstation" is any Windows computer which runs a VFP executable. These days that can mean:
>
>- a physical Windows workstation
>- a Windows virtual machine in a standalone VM environment or a virtual desktop in a virtual desktop infrastructure (VDI) environment
>- a session on a Remote Desktop Services host computer (formerly called Terminal Services)
>
>Those settings do NOT apply to computers which only store the VFP data files and which do not run any VFP executable.
>
>They are a response to issues introduced with SMB 2 in Windows Vista. At that time they first manifested as index corruption. I don't recall seeing any incidents of true "data loss" per se but a corrupt index can make it look like rows are missing, even if they are still present in a DBF.