>>>>>>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
>>
>
>reordered...
>
>>
>>
>>As a sysadmin my preference is to disable SMB1 unless it's needed by really old devices or Windows versions, leave SMB2/3 enabled, and apply the Alaska Software registry changes to workstations and/or session servers.
>
>Let me speculate that with you as their sysadmin AT LEAST the symptom/occurrence of not being able to connect atter disabling SMB2/3 would not have occurred, as you are aware of latest new installs not including SMB1 and older updates deleting them silently after period of not using it...
>
>Armchair diagnosis on rather scetchy symptoms is hard, esp. if there is a minimal chance of side effects or 2 factors being involved.
>First order of business is to find the reason of corruption and enable them to work uninterrupted in the future as well.
>
>Possible causes are with my percentage guess :
>
>50% SMB/oplocks troubles
>15% other weaknesses introduced in new windows versions (ex: drive letters mapped to shares loosing/reestablishing connection)
>10% faulty LAN wiring (Cat-5 cables, switches/hubs interconnected, notoriously unreliable WLAN "cable")
>05% HW problem on server (disk sectors, cables)
>10% intermediate SW running on server (AV, virus)
>05% vfp coding errors, as only basic stuff is do ne and across many tables/routines errors crop up NOW
>05% acts of Gods, nature, saboteurs and other reasons to get to 100
>
>See my post of 25/09/2018 22:52:32 local time for my approach - reasons are:
>OP was 1 month ago, 20 users aggravated/work time lost for all certainly above 100 work H plus at least 2 days of admin and 3 days of Sylvain time. Cost: non-trivial.
>
>Running vfp app against dedicated XP server from virtualized local XP clients should prove network stability and vfp code quality, proiding a base user can work next week without interruption.
>
>I agree a competent and dedicated admin probably could keep settings for SMB3 workable with small worker time lost and little admin time.
>Perfomance during last month suggests that admin is either incompetent or Sylvain was unable to pressure/motivate him enough.
>So repeat long interruptions are probable every time MS craps on SMB in Update again.
>
>
>>Hmm, SMB1 has multiple nasty security vulnerabilities and has been deprecated in Windows for a long time. Disabling SMB2/3 is not recommended and reduces functionality of more recent versions of Windows:
>>https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and
>>Specifically, the warning and header information at the top of that link.
>
>True. But the typical back-office data entry program I visualize should be able to run on server hosted XP VMs accessed via MSTSC/RDS hitting a XP server backend on a 32GB quad or hexacore on SSD with ease. I BELIEVE you could keep SMB1 broadcasting/vulnerabilities inside the subnet created by virtualization software inside that machine - in practice I would slap a cheap router in front of that machine creating a cascading subnet and only tunnel through via MSTSC ports and special rules, separating that app and XP vulnerabilities from nomal network ;-)
>
>As written in other post, if the app needs to be integrated into client desktops and is company survival relevant, bite the bullet and switch over to any SQL backend (as hiring competent admins probably is more costly in the long run)

If the problem proves intractable then I agree, switching to a sandboxed environment running SMB1, or an RDBMS back-end are reasonable approaches. Management at his firm should do a post-mortem, figure out what this incident costs them and whether it's worthwhile making a switch.

Still, businesses are reliably running on VFP tables on "regular" LANs and SMB2+ without any special measures being taken or skilled sysadmins watching like a hawk 24/7. The main downside is that if something does go wrong there are so many potential causes that it's hard to know them all and test them in a systematic manner.

As a side note the OP started another thread, it seems he's narrowed it down to a single table consistently getting corrupted indexes. I suggested checking for CHR( 0 ) or similar bad characters in the table data, which I've seen cause this in the past. Haven't yet heard back.

UPDATE: re XP server - should point out to lurkers that XP has a 10 connection limit. If more simultaneous connections/users are needed then Server 2003 would be needed (obsolete - might be hard to obtain). Could use modern server versions but as you point out, even if SMB2+ are disabled, Windows Updates may enable them again - potential maintenance headache.

Another edge case: network devices with licensed connection limits e.g. Cisco ASA used to have 10 connection limit by default. If the limit is exceeded weirdness can ensue.