Access crash with error "Your network access was interrupted"

A lot of changes at once, so not going to be the simplest to see exactly which change cause the issue.

What is the power profile for the workstations? And are the NICs allowed to be shut off to save power? Are your servers virtual or physical? Also, what type of NIC does the server have in it? If the answer is Broadcom, please be sure to turn off VMQ.

I turned off Network power management on one of the workstations to see if that will help.

This is a physical server (no virtual environment)

I checked and the VMQ VLAN Filtering option is disabled on both server NICs

Most of the time, the computers are being actively used when the error appears.  So I doubt the system is idle long enough for the NIC to be turned off.  However, at this point, I'm willing to try anything.

I'll report the status tomorrow, but still welcome any additional suggestions in the interim.

There is nothing obvious here, but Access is known to be sensitive to even the smallest dropouts in network traffic. That's why it's a no-go to connect workstations with frontends to server with backend via WiFi.

I would go for these two topics - at least for ruling them out:

1. You mention, that users' default folders are moved to the server. Check, that this doesn't include temp files, as usage of an Access frontend can create a lot of temp files.
2. Also, even though the network hardware has worked for a long time, try replacing the Netgear switch. As it is unmanaged, it could be any recognised brand like a HP ProCurve. Speed is of little importance for testing - any (old) proven model with Fast Ethernet (100Mb/s) will be fine.

Copied the database to the local C Drive on each workstation

how could you get network issues for that database if you were using a local connection?

try to use fixed IP addresses for each workstation and make sure that the DHCP server is aware of those.

Sara

Copying the database to the local workstation meant just the front end.

Did you see if having the front and back ends on the local machine works? If not, then you really have an issue.

What else is on the network? Just doing folder redirection would've  been cause for an increase in network traffic. The key may be in reducing some of the bandwidth usage overall.

@Gustav - I originally had the AppData folder moved to the server, but moved it back to the local PC when I discovered it broke the iCloud for Windows software.  I have an 8 port Fortigate 60e router installed.  I can move the server and a few select PCs directly to the back of the router to see if that has an effect.

@sarabande - masnrock is correct, I was only referring to the front end.  The server has a static IP, but the workstations are DHCP.  I don't see the benefit if assigning static IPs to the workstations

@masnrock - I could copy the front end/back end to a separate system and run them locally, but first I would have to update all the network links within both files, thus tainting the test files.  However, I will keep this as an option to verify the stability of the database files themselves.  

Nothing else is really on the network.  They connect to vendor websites, and an internal file server.  Nothing that would tax or max out the network bandwidth.  Folder Redirection is not fully enabled on all workstations, but was only half enabled before the server upgrade.  The only other thing that I can think of is that I keep the Outlook PST files on the server as well.  90% of the PSTs are under a gig, with one user having about a 5GB PST file.  However, no one has complained about any slow Outlook performance.

On a partially related note, I disabled power management on one of the PCs yesterday.  Today, that PC did not encounter a single network interruption error.  I have applied the change to two other PCs to see if this potential fix is the correct solution.

I don't see the benefit if assigning static IPs to the workstations

static IP's is a effective way to avoid that devices which were using a different DHCP server  (by accident or by configuration) would use a duplicate IP address. addititionally it prevents from issues due to cached data at the server which may still refer to a previous IP address while the client has got a new one, for example because of a new login.

one user having about a 5GB PST file

the huge open PST files together with power management might cause the server to timeout when the client was asleep. in my opinion this is a good chance that the tcp/ip subsystem goes down and doesn't recover. check the event logs both from server and client.

Sara

Note that as soon as Microsoft comes out with a fix for this, you'll want to re-enable leasing as it's a performance hit for everything else.

Bookmark this:

https://support.office.com/en-us/article/fixes-or-workarounds-for-recent-issues-in-access-54962069-14f4-4474-823a-ff7e5974a570

 and keep checking back to see when they get a fix for this.

Jim.

@Jim - Thank you for the URL reference.  I was unaware that I had to apply that registry fix to both the server and the workstations.  However, I did not read about any performance issues when disabling leasing.  Can you please elaborate on the services that would be negatively impacted by this change?

First, doing the server should be sufficient.   The recommendation from Microsoft of doing both client and server is them playing safe and trying to cover all the situations that might exist.

 Leasing in SMB2/3 is a performance feature in that it allows client side caching of served files.  By turning it off, you are no longer allowing that.  

 While that helps with Access for this specific problem, it's bad for any other type of file, which now has to be always read/written from the server over the network.  So it's a performance hit and you'll want to re-enable it when the Access (actually it's a windows bug) is fixed.

JIm.

Cool!  Good to know.  Thanks for the share.