>Some of our clients have reported issues with our app, and a pattern is starting to form. A common theme is that they leave the app open and idle for a while, and when they come back the app will crash, usually with an error that points to the network ("Error reading file", etc.). The problem seems to have started when the clients upgraded workstations to Windows 10. I'm gathering more info on the servers, but they are all likely running Windows Server 2016 or 2019. This is a NEW problem for us, so the old tricks may not apply. Here are some details:
>
>* We are using VFP 9 SP2 + hot fixes.
>* Most of these clients have the data in SQL Server, although there are still some shared DBFs and other files on a shared/mapped drive.
>* We have another non-VFP app that accesses shared database files over a network share, and it is experiencing similar problems.
>* We set the power settings to prevent the workstations from going to sleep.
>* In the network card settings, we unchecked "Allow the computer to turn off this device to save power".
>* Windows 10 + Server 2016/2019 means they are most likely running SMB 3.1.1.
>* We are already disabling the cache settings that were introduced with SMB 2.0 (DirectoryCacheLifetime, FileNotFoundCacheLifetime, FileInfoCacheLifetime) on the workstations.
>* We have NOT tried "net config server /autodisconnect:-1" (just learned about it today), although that has never been a requirement for us in the past.
>* We keep a shared SQL Server connection open for the entire time the app is open. On at least one workstation, the SQL Server connection is being disrupted as well, so the problem may not be limited to SMB.
>* We are using SQL Server Native Client 10.0.
>
>We are still gathering information, but these newer versions of Windows seem to be more sensitive to idle activity. Is anyone else seeing this behavior?

We have seen the same thing. We've added code on a timer and some "dummy tables" to go in and process. If we're on a File Server system we will add bogus records to a .DBF and then randomly DELETE and PACK the file. If we're on a SQL Server system, we will add records to the table, do queries, etc.

We setup two processses, one launched from the first. We pass the HWND of the first as a command-line parameter to the second. There we can send messages to the second to tell it to do its work. When the first shuts down it sends the shutdown message so it also shuts down.

It's jumping through hoops, but it's a way to keep the network alive by constantly exercising it.