Normally that error message means you are losing connectivity to the network or your hard disk when idled. (can also happen during usage in some cases)
Turn Off Power Saving
===========================================================================
First if this happens when you step away from the computer and come back then turn off any power saving features that can cause the connection to the network to fail like going into some kind of sleep mode.
In addition there is an AutoDisconnedt feature in Windows 10 and later that will disconnect a mapped drive letter and random intervals which will also cause this error.
You can usually prevent this from happening by connecting to the backend database by NOT using a mapped drive letter.
Instead, you should connect using a UNC path like this:
\\ServerName\TATEMS\tatems2005be.mdb
Turn off AutoDisconnect
==============================================================================
If you can't connect using a UNC path like the one shown above, then the following instructions describe how to turn off AutoDisconnect
On Windows 10 or 11 the first thing to change is the Auto-disconnect feature on the workstation If for some reason you
You can update the timeout feature to make it longer by updating the registry for AutoDisconnect to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters autodisconnectvalue ffffffff
WARNING: "Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to re-install Windows to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk."
Also you can turn off the Autodisconnect feature on the computer affected. You might also consider turning off this feature on the server too if multiple computers are affected.
- Click on Start>All Programs>Windows System
- Right click on Command Prompt and choose Run as Administrator.
- If you are prompted to click Continue to run the application, click Continue.
- In the Command Prompt screen, type in the following and then press enter: net config server /autodisconnect:-1
disable or turn off AutoDisconnect or Auto Disconnect Command Prompt
There is also a group policy method and other methods for chaining the AutoDisconnect feature here
And a method using a startup script if Windows keeps changing the AutoDisconnect back to that way it was when it was causing the problem here:
Other causes
=====================================================================================
Here are some other possible culprits that may be causing the Disk or Network Error:
As stated above, Check and turn off any power saving settings for the network adapter and hard disks.
One other potential fix we found is this:
TURNING OFF NETBIOS AT THE SERVER. (ie: Network Connections->Local Area Connection->TCPIPv4->Advanced->WINS->Disable NetBIOS over TCP/IP
And this archived KB article from Microsoft may also be a solution for you
Also if you are connect via a wireless network then you'll need to improve or upgrade the wireless network and adapters or move to 1GB wired Ethernet network
Hopefully one of those tips above will help.
Last Resort - Move to Remote Desktop Services Or The Cloud
The other option as a last resort that is guaranteed to work is to run TATEMS on a Remote Desktop Services server with the data file also being stored on that same server, and have each user remote in to TATEMS using the instructions at the link below.
Of you can sign up for our cloud service which puts your TATEMS and data on our cloud server.
More bakground on causes of Disk Or Network Error From Various Microsoft Access MVP's on the Office Forums
Access databases are heavy users of networks and are sensitive to any network
problems. Most other applications will try again to get the data if they run
into a problem. So if word tries to fetch a document and something goes
wrong, it will probably try to fetch the document again, and you will never
see a message that something went wrong the first time it tried.
The problem may not be necessarily that there's a lack of network but
rather merely a network disruption. I know that your Network Admin says
it's not a network problem, but if there's a funky network card on the
network that causes more disconnection/disruptions, it's enough to trigger
the errors. This is even true even if the computer with the funky network
card can surf the web and use other network resources without any
apparent disruptions.
And the disruption can be for a very tiny interval.
What it means is that when Access/Jet/ACE last tried to ping the
locking file for the data file across the network, the ping failed.
Jet/ACE gives up at that point (though there may be some retries in
there), which is probably a good thing, as the last thing you'd want
is a locking file that is reporting incorrect information for other
users.
Any dropped packet during Jet/ACE communication is going to cause
the error.
It can be caused by all sorts of issues, including software running
on the server that can interfere with the networking redirector.
Access/Jet/ACE is the canary in the coal mine. Other apps may have
no difficulties, but this is precisely because what they are doing
across the network is not nearly as complicated as what Jet/ACE does
with locking its data files for the purpose of allowing multi-user
access.
Have any new computers been added to the LAN? I had a client whose
database ran fine for years, and when they added a new laptop,
suddenly things went wonky. Upgrading the NIC drivers on the laptop
fixed the problem.
It could also be a new server, router, switch or hub, or any other
component of the network. It doesn't have to be directly between the
machine experiencing the problem and the file server where the back
end is stored -- since network packets can go through any number of
hosts and get passed on by them, all the hosts connected to the LAN
are potentially causes of "pollution" of the LAN traffic with
packets that Access/Jet don't like.
Something *did* change. It doesn't have to be in the
software/hardware configurations of the workstations/servers
directly involved with your Access applications. Nor does it have to
be on your local subnet -- it can be something anywhere on the LAN
that is connected to your local subnet.
Also, keep in mind that Windows Updates if automatically applied are
constantly changing the software configuration of your workstations
and servers.
It's a terribly difficult thing to troubleshoot.