>>>>>>>>>>>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

Took a bit longer...

From Index thread:
>Except for power failure or application shutdown in a middle of a write, what can cause this ? And how to avoid it ?

Sometimes wrong index expresions coming across records causing failure
Bad sectors on a HD/SSD could evoke such failures sporadically
About any HW / connection issue (LAN, SATA cable, DC power to disc) from corrosion to cable break "mostly functioning"

>>>>>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.

SMB1 is a reliable workhorse, but IIRC has problems in security due to broadcasting for plug&play, which lead to being disabled in one of the latest versions/updates in Win 10. The core functionality is still included, but has to be enabled, AFAIK both on server and client MACHINES, the corresponding services for the intended role. Windows will remove SMB1 after Upgrade if not used/enabled silently, will not install in new installs unless specifically prodded. If that is done and files cannot be accessed, system is screwed somewhere in the registry.

Politic rant:
mission critical SW IMO should not run with dbf data stores on new versions of Windows - MS made it clear that they want to kill ISAM file usage in Vista days. Since then SMB/oplocks made multiuser dbf on a fileserver a liability on current OS.

If the vfp app used by 20 users is survival critical, only 2 options, both incurring some cost and effort:
1) bite the bullet, move data store to SQL backend
2) keep ISAM dbfs, but forego modern OS, stay on XP for client and file server, perhaps both in a VM.

Stop-gap first step is to grill the admin if he checked SMB1 activated and enabled on server AND client before testing.

As newer Win10 clients have ample memory and from the vfp access described implemented in the app, spinning up a XP in vitrualbox or VMWare with only the vfp app installed on a 0.5 - 1 GB RAM XP client with single core CPU on each client should be doable.

Hooking up a XP server in a dedicated machine for a first test could be done on a clunker wth ample RAM, kicking suspect server to identify the problem. After that, all newer OS problems including Windows update are nonexistant.

If errors still crop up with dedicated XP hardware server accessed by client XP VM on each client machine , network is prime suspect. Faulty wires can be circumvented by hosting all XP clients on a server, using the wiring only for the RDS used to steer the clients and show the screens.

Such setups work (and in more cases than not are faster/snappier to work on compared to "traditional" client drawing dbf-data across the wire if the ratio of moved dbf to wire capacity is large) rather well. In my old company more than hundred VMs on a beefy serverwere accessed via internet, first via RDS, later with one of the packages displaying GUI in browser (not via FoxInCloud) for security reasons.
Yes, they had some issues to overcome, but I was not in that loop and they had no real show-stoppers. Myself tended a dozen VM hosted on high-security server data crunching TB of insurance big iron data on hypervised 32 cores - only running debugger over internet is tedious ;-)

Watershed decisions:
Usage of the app is tantamount.
- If the app needs no contact with internet/things from other applications, keeping app AND dbf in virtualized XP becomes credible.
- If all those client VMs are on a dedicated server, security is hightened.
- If the app needs to communicate with email, printer, scanner, browser, file system of client machine, client VM has to be installed on client machine. Danger grows higher with each service from HW needed - if the app is integrated on client as "installed software" in contrast to "let me enter that data in the app" that argues for upgrading the backend to C/S SQL, which allows the vfp app to stay directly installed in client Win 10 without going against current MS mindset.

Anything else is trying to move upstream in waters MS has crapped in repeatedly before.

Moving to a SQL-Server backend incurs programming cost - but has other benefits as well. No realistic cost/benefit ratio can be done without surveying code, needs and similar stuff. Even if move to SQL is not targeted, IMO a data layer abstracting vfp data functions ***on a fileserver app*** incurs negliable runtime overhead but will offer programmatic hooks to identify problem areas easier.

been there, done most of the above - doable, if planned with sane mind

thomas