>>>>>>>>>>As for the SMB issues, I've deactivated SMB v2/3 on the (virtual) server, but doing so also prevent the users from accessing the server.
>>>>>>>>>
>>>>>>>>>That hints for me to deactivated SMB1 - perhaps double check ?
>>>>>>>>>You NEED SMB to access remote files, but only SMB1 is ISAM safe...
>>>>>>>>
>>>>>>>>If I understand you correctly, I should deactivate SMB2/3 and let only SMB1 activated?
>>>>>>>>
>>>>>>>Correct
>>>>>>
>>>>>>If I deactivate SMB2/3, the users can't acces at all the server
>>>>>
>>>>>Then you have a screwed up system: NT, W2K and XP did just that with SMB1 ;-)
>>>>
>>>>What do you mean by screwed up system? The server is Windows Server 2016 running in a virtual machine (VM) and all our user are using Windows 10.
>>>>
>>>>We're beginning to think that having the database on the VM is the cause of our problems. Maybe transfering the database on a "real" physical server will resolve the problem?
>>>
>>>same system as in "Index jeep corrupting" thread?
>>
>>Yes
>
>Gimme 60 min to think options through while getting some fresh air and buy groceries - have some ideas, but must put them in effort/possible solution percentage order, which is not easy having no further info about # of users, HW system and net wiring stats, SW/app complexity.
>
>Are your data accesses hardcoded xBase / vfp commands and functions scattered directly in your code using text literals ?
>How are paths/filenames built in your system ? Logical Disk letter "net use", SMB share names or IP URIs ? Easy to fix via variables fed to functions/methods ?
>Anything more about net wiring/setup, Server VM and typical client machine # and HW helpful

There are about 20 users of the application. The data is accessed using VFP commands. We're using \\ServerName\DriveName\DatabasePath format to open tables. No hardcoded path in the application, other than a global SET PATH in the main program. The database is on a VMWare VM running Windows Server 2016