SMBLeasing?

What is the exact error your users are receiving?  Disc and File error are not symptomatic of the Windows 10 SMBLeasing issue (unrecognized databse...).

Does your db establish a persistent connection at the startup?
Are all the users on the same wired LAN?

Why in your choices are you wanting to change bitnesses if you migrate to 2016?  I would stick with 32-bit unless there was a distinct reason to change (which in 99% of cases in not the case).

"What is the exact error your users are receiving?  Disc and File error are not symptomatic of the Windows 10 SMBLeasing issue (unrecognized databse...)." From the customers description (I don't have direct access to it at the moment) "Disc or file error. The error may not result in incorrect macro name Etc.etc."

'Does your db establish a persistent connection at the startup"  Yes

"Why in your choices are you wanting to change bitnesses if you migrate to 2016?" I am assuming that if the only time we have a problem is when we install onto a clients 64 bit environment that this may have something to do with it.

In my experience, disk errors usually have to do with networking, saturation, wireless connections and the likes.
Have you validated they are running on a wired LAN, no wireless anywhere in the mix?
What about network saturation/latency...?
What is the db size?
When was it last compacted?
The db is split and each user has their own local copy of the fe, no sharing a common file?
Does the error ocur randomly, or is this a reproducible issue?

Latency was less tha 9ms and typically 1ms
The current issue is with an external drive rather than a network. But all other issues have been with servers.
DB size is 4MB
The last time was a week ago where I opened the data and got a message that the data needed repairing. It then works fine for a week then regular problems there after 3 or 4 times per day when all fields go to error.
Each pc has it's own front accessing same data on the external hard drive. On one system it erred every 90 minutes. This one I don't know because it is used randomly

Thank you for that Daniel. I was aware of a previous post where we tried the smbleasing fix and it has indeed caused serious problems for our client.. They now have only one pc running our program out of three. The other two run so slow that they are unusable. It really is making my company look stupid. they, of course, do not believe that it is a Microsoft issue. So we are the bad boys at the moment.  I read the entire article and your comments. I will be trying to get into the client next week. We will be moving the data to another location and running that small batch file and hope that it fixes the issue.

Very helpful. Thank you

As for them not believing you, simply send them the link to MS' official page on the issue, this is what I've done.   And yes, Microsoft is making the entire community look very bad.  Two years to address such a critical issue is two year too long.

https://support.office.com/en-us/article/access-reports-that-databases-are-in-an-inconsistent-state-%EF%BB%BF-7ec975da-f7a9-4414-a306-d3a7c422dc1d

For some reason, as a bat file, this will not run:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

Anybody know why?

Any reason why this would not work:

1.      At start type in cmd, don’t just hit return, select “Run as Administrator”
2.      Drop the file into the folder that the command prompt opens up as this time (probably C:\WINDOWS\system32)
3.      Then just type in accessfix2.
4.      The output you should get is;

C:\WINDOWS\system32>accessfix2
C:\WINDOWS\system32>reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /v FileInfoCacheLifetime /t REG_DWORD /d 0 /f
The operation completed successfully.
C:\WINDOWS\system32>reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /v FileNotFoundCacheLifetime /t REG_DWORD /d 0 /f

The operation completed successfully.
C:\WINDOWS\system32>reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /v DirectoryCacheLifetime /t REG_DWORD /d 0 /f

The operation completed successfully.

C:\WINDOWS\system32>

The very slow loading and general operation speed was increased significantly with this
This was the solution: Access 2002

1. For the Microsoft Access Runtime executable:-

 
C:\Program Files (x86)\Microsoft Access Runtime\Office10\MSACCESS.EXE
 
In properties change the Compatibility Mode to Windows XP (Service Pack 3)
 
 

1. Amend the following registry key to 50000 (Decimal)

 
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\Jet 4.0\MaxBufferSize

Hope that helps someone else.