<div>
A lot of changes at once, so not going to be the simplest to see exactly which change cause the issue.<br />
<br />
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.
</div>


<div>
I turned off Network power management on one of the workstations to see if that will help.<br />
<br />
This is a physical server (no virtual environment)<br />
<br />
I checked and the VMQ VLAN Filtering option is disabled on both server NICs<br />
<br />
Most of the time, the computers are being actively used when the error appears. &nbsp;So I doubt the system is idle long enough for the NIC to be turned off. &nbsp;However, at this point, I'm willing to try anything.<br />
<br />
I'll report the status tomorrow, but still welcome any additional suggestions in the interim.
</div>


<div>
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.<br />
<br />
I would go for these two topics - at least for ruling them out:<br />
<br />

<ol type="1">
<li>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.</li>
<li>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.</li>
</ol>
</div>


<div>
<blockquote>
Copied the database to the local C Drive on each workstation
</blockquote>
<br />
how could you get network issues for that database if you were using a local connection?<br />
<br />
try to use fixed IP addresses for each workstation and make sure that the DHCP server is aware of those. <br />
<br />
Sara
</div>


<div>
Copying the database to the local workstation meant just the front end.<br />
<br />
Did you see if having the front and back ends on the local machine works? If not, then you really have an issue.<br />
<br />
What else is on the network? Just doing folder redirection would've &nbsp;been cause for an increase in network traffic. The key may be in reducing some of the bandwidth usage overall.
</div>


<div>
@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. &nbsp;I have an 8 port Fortigate 60e router installed. &nbsp;I can move the server and a few select PCs directly to the back of the router to see if that has an effect.<br />
<br />
@sarabande - masnrock is correct, I was only referring to the front end. &nbsp;The server has a static IP, but the workstations are DHCP. &nbsp;I don't see the benefit if assigning static IPs to the workstations<br />
<br />
@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. &nbsp;However, I will keep this as an option to verify the stability of the database files themselves. &nbsp;<br />
<br />
Nothing else is really on the network. &nbsp;They connect to vendor websites, and an internal file server. &nbsp;Nothing that would tax or max out the network bandwidth. &nbsp;Folder Redirection is not fully enabled on all workstations, but was only half enabled before the server upgrade. &nbsp;The only other thing that I can think of is that I keep the Outlook PST files on the server as well. &nbsp;90% of the PSTs are under a gig, with one user having about a 5GB PST file. &nbsp;However, no one has complained about any slow Outlook performance.<br />
<br />
On a partially related note, I disabled power management on one of the PCs yesterday. &nbsp;Today, that PC did not encounter a single network interruption error. &nbsp;I have applied the change to two other PCs to see if this potential fix is the correct solution.
</div>


<div>
<blockquote>
I don't see the benefit if assigning static IPs to the workstations
</blockquote>
<br />
static IP's is a effective way to avoid that devices which were using a different DHCP server &nbsp;(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.<br />
<br />

<blockquote>
one user having about a 5GB PST file
</blockquote>
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.<br />
<br />
Sara
</div>


Gustav Brock

<div>
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.<br />
<br />
Bookmark this:<br />
<br />
<a href="https://support.office.com/en-us/article/fixes-or-workarounds-for-recent-issues-in-access-54962069-14f4-4474-823a-ff7e5974a570" rel="ugc">https://support.office.com/en-us/article/fixes-or-workarounds-for-recent-issues-in-access-54962069-14f4-4474-823a-ff7e5974a570</a><br />
<br />
&nbsp;and keep checking back to see when they get a fix for this.<br />
<br />
Jim.
</div>


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


<div>
First, doing the server should be sufficient. &nbsp; The recommendation from Microsoft of doing both client and server is them playing safe and trying to cover all the situations that might exist.<br />
<br />
&nbsp;Leasing in SMB2/3 is a performance feature in that it allows client side caching of served files. &nbsp;By turning it off, you are no longer allowing that. &nbsp; <br />
<br />
&nbsp;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. &nbsp;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.<br />
<br />
JIm.
</div>


<div>
Cool! &nbsp;Good to know. &nbsp;Thanks for the share.
</div>


<div>
<div class="content wysiwyg-content">
We use a back end / front end Access 2016 database. &nbsp;The frontend contains the forms, whereas the backend stores all of the data. &nbsp;This has been working well for the past 8 months. &nbsp;Two weeks ago, we upgraded from a Windows 8 file server to a Windows 2016 domain environment. &nbsp;All 10 workstations were added to the domain, along with 15 new user accounts. &nbsp;All of the files were successfully migrated to the new server using robocopy. &nbsp;We also implemented a GPO to enable Folder redirection for the users' Desktop, Document, Favorites, Photos, Music and Videos. &nbsp;We also have a GPO to map network drives.<br />
<br />
Since the move, users are receiving the following error about once an hour when using the FrontEnd, &quot;Your network access was interrupted&quot;. &nbsp;We applied the following changes to try and rectify the issue, but nothing appears to help:<br />

<ul>
<li>Turned off NIC Teaming on the server</li>
<li>Copied the database to the local C Drive on each workstation (instead of the user's desktop, which resides on the server)</li>
<li>Updated the Frontend so that it uses \\UNC instead of the Mapped drive</li>
</ul>
<br />
None of the networking hardware has changed. &nbsp;All workstations are connected via RJ45 to a Netgear JGS524NA switch, and a Fortigate 60E router. &nbsp;We have had no other network related complaints other than a few random instances where the office chat software could not connect to the office shat server (external server). &nbsp;There have been no reports about access the share folder on the server, or email connectivity.<br />
<br />
Any suggestions are appreciated.
</div>
</div>


We use a back end / front end Access 2016 database.  The frontend contains the forms, whereas the backend stores all of the data.  This has been working well for the past 8 months.  Two weeks ago, we upgraded from a Windows 8 file server to a Windows 2016 domain environment.  All 10 workstations were added to the domain, along with 15 new user accounts.  All of the files were successfully migrated to the new server using robocopy.  We also implemented a GPO to enable Folder redirection for the users' Desktop, Document, Favorites, Photos, Music and Videos.  We also have a GPO to map network drives.

Since the move, users are receiving the following error about once an hour when using the FrontEnd, "Your network access was interrupted".  We applied the following changes to try and rectify the issue, but nothing appears to help:
Turned off NIC Teaming on the server
Copied the database to the local C Drive on each workstation (instead of the user's desktop, which resides on the server)
Updated the Frontend so that it uses \\UNC instead of the Mapped drive


None of the networking hardware has changed.  All workstations are connected via RJ45 to a Netgear JGS524NA switch, and a Fortigate 60E router.  We have had no other network related complaints other than a few random instances where the office chat software could not connect to the office shat server (external server).  There have been no reports about access the share folder on the server, or email connectivity.

Any suggestions are appreciated.

Access crash with error &quot;Your network access was interrupted&quot;

Microsoft Access is a rapid application development (RAD) relational database tool. Access can be used for both desktop and web-based applications, and uses VBA (Visual Basic for Applications) as its coding language.

Microsoft Access

Networking is the process of connecting computing devices, peripherals and terminals together through a system that uses wiring, cabling or radio waves that enable their users to communicate, share information and interact over distances. Often associated are issues regarding operating systems, hardware and equipment, cloud and virtual networking, protocols, architecture, storage and management.

Access crash with error &quot;Your network access was interrupted&quot;

Access crash with error "Your network access was interrupted"