>Hi all of you,
>
>We have an application which VFP-based and has started to behaved very badly on machines that run the latest WIN10 version. There is already some public feedback on this 1803 version. But nothing specific to VFP.
>
>The issues we ran into for VFP are quite serious and also difficult to track. Why? because the application that refused to worked is indeed VFP-9 (latest patches of course). But it it fully virtualized (both the vfp and its VFP*.dll and the related dlls and ocx-es).
>
>I have formally verified that the Windows 10 Version 1709 works flawlessly - I understand most corporations would not used the advanced 1803... But well our application has already stopped working properly on home PCs with an "aggressive" auto-update pattern.
>
>We are eagerly looking for solutions. That may possibly include changing a number of stuff, including dropping our shellExecute (SHELL32.dll) commands that display a curious behavior and - more serious issue - changing the virtualizer we use for a new one (replacing molebox virtual box with the enigma virtualizing engine).
>
>Any feedback on issues with this recent windows update is welcome, VFP-related OR NOT!
>
>Daniel

This is from a discussion in another forum:

> We are experiencing some huge issues with multi-user network file sharing on version 1803 of Windows and VFP9 SP2. Here are a few of the issues we see:
> 1. Blank records written to the database. A system will write a complete record with values in all fields, but the record is blank in the table.
> 2. Records that are written but don't appear for other users until the table is closed. If session A opens a table and adds 5 records, session B will see that the extra 5 records are there, but they will either be blank or will appear to have data from a previous record in them. Once session A closes the table, the data appears for other sessions.
> 3. Records will be appended to a table, and will end up just creating a duplicate of a previous record instead.
>
> These all appear to be issues with caching or delayed writes of some sort.
>
> I've seen various combinations of these problems very consistently across dozens of installations in the last couple of days. The only solution has been to have the users roll back to the previous build of Windows.
>
> We've tried disabling oplocks on the client and server machines and verifying offline files are not enabled, but haven't found a solutions.
>
> Has anyone else seen anything similar? Suggestions? This could be a disaster if we don't figure it out.
>
> Thanks,
>
> Paul



So here is what we have found. The problems seem to be specifically caused by the KB4103721 update to Windows 1803. We were able to resolve the problem by removing that update as a temporary solution.
We have now found that by disabling some of the SMB caching parameters.

Open a powershell administrative prompt. (right click on the start button)
Execute the following two commands:
set-smbclientconfiguration -DirectoryCacheLifetime 0
set-smbclientconfiguration -FileInfoCacheLifetime 0

You can then run:
get-smbclientconfiguration

to verify that the values are set.