Random Network Error popping up on MS Access

I will reach out to the user and check connection.   I will also find out the server and run a ping test to it to find out if there are packet drops.

@John I do not know if they are on a wireless network or a wired network.   I will ping the user and find out what the server name is and run a ping to it.

Usually ... that error means exactly what it says.  Some sort of a momentary glitch in the network connection. Believe me ... it does happen.
As noted, a wireless connection is very problematic and not recommended.

Another question:
Does each user have their own copy of the Front End UI on their workstation, linked to a common back end on a server or share drive?
That is recommended scenario for Access databases.

I did not setup the configuration so I am truthfully unsure.  They have the access shortcut they run from their desktop that hits whatever external IP and lets them in.   I think their database is located on their DC.  That means everything is local.

Well ... guess I'm not understanding the setup.  Nonetheless ... it's difficult to troubleshoot a problem of this nature because there are many possible factors involved.  But the best guess is still some sort of network problem.  Is there an IT dept that could get involved ?

"that hits whatever external IP and lets them in."
Are they using Remote Desktop or some sort of VPN connection?

"local' ... then why would an IP address be involved per se ?

I know the database was migrated to their domain from a former provider.   How can I edit the shortcut to see what address its connected to?  They have been working with this just fine.  I know multiple people share the same access dbase could it be a limited number of connections which may be causing them to disconnect

"How can I edit the shortcut "
Right click on the Shortcut, and select Properties. This will show the path and location of the db.

"I know multiple people share the same access dbase "
Again ... you need (in general) to determine the following:
Is there literally just one physical Access db (ACCDB or MDB), and each user is working out of the same physical db?
IF ... this is the case, this in general is the worst case scenario.

FWIW ... in a perfect world, the max number of connections allowed to a single physical db is 255. But in the real world, it would be much less for sure, and many factors are involved.

As the others have said, a problem with the network connection, and that can take many forms:

1. Bad NIC driver, cable, port on switch/router (an actual network problem).
2. Windows disconnecting an in active mapped drive.
3. GPO that uses REPLACE for a mapped drive instead of UPDATE.
4. Antivirus/behavior monitoring software.
5. Power management features idling the NIC.

There's also a recent Windows bug that you should be aware of starting with build 1802.  That's covered here:

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

under:

 "[WORKAROUND] Access reports that databases are in an 'inconsistent state'"

 In short, anything that interrupts the networking can cause that error dialog.

 You should start looking for a pattern; always the same stations?  same time of day?  Do they sit idle for long periods?   What were they doing at the time, etc.   With the frequency your seeing, you should be able to pin this down pretty fast.

 Also the typical questions; when did it start?  what work was done around that time?  anything replaced or updated?  etc.

Jim.

I know the setup was quick and dirty.  They have the access db running off a cheapie workstation.   However having said that I think they are opening and access the dbase locally on that unit as well.   So perhaps its the nic on the machine?  Driver? bad hdd?  I know the unit is very old.  This is one of those some one else set it up and now theres problems and I gotta fix it.  -_-

It looks like there are some redirected folders that are running off the DC where all their data was migrated to.   It seems that their short cuts are pointed to this old pathname.  I found it in DNS and removed it.   I have re-created the shortcut to point to the correct location as well as starting a continuous ping to the server to see if there are any packet drops.  Will keep you posted.

OK.

Jim.

Looks like the disconnection is still happening.  Here is what they sent me yesterday.
2 disconnects.   She left her machine on but it went into hibernation I cant remote into it until she gets back.  I asked her to update me on the packet loss from the ping tests I did.   Will keep you posted.  This is getting aggravating.

hibernation

That will certainly break the network connection.   Stations should not be set to go to sleep or hibernate.   I always set people for an "always on" setup and make sure that the NIC is not allowed to sleep.

Of course there is some user training here too; they should be closing out of their Access apps.

Jim.

I may have turned that off.   I think the problem is where the dbase is currently sitting the shortcut is not properly pointed to it.  I reached out to the dbase administrator to find out where he put the actual file and will point the shortcuts to it.

So get this LOL!  The database is in more than 1 location.   I did happen to locate where the correct up to date database sits.   I will try and setup a shortcut to this path rather than using a redirected folder path this time and see if the disconnect stops.   I had no idea the dbase admin knew this was setup in various locations.   Talk about frustration!

Also found out Instead of making a shortcut to point directly to the server, we're supposed to use a local copy of one of the tables to initiate the connection.
The admin is telling me There should be two shortcuts on each desktop:
One points to the clienttrak path c:\apps\clienttrak.accdb
- the second one is a "refresh" shortcut that copies that same remote database to the local one to keep it compacted.  That shortcut is a BAT file called "SATS Refresh.BAT" (a copy is in y:\apps), but here is the code for it:
Y:
cd\
cd apps
copy clienttrak.accdb c:\apps

Users are supposed to run the "refresh" command file about once a week to keep it working efficiently, and I'd run that first before testing the login shortcut.

What your describing is a normal setup; a "split" app.

This is where the Front End (everything but the data) is on each users PC.  The "back end" has just the data, and is the only thing shared.  The batch file you speak of is for updating the Front End for each user.

Jim.

Jim where would the disconnect be happening then? This is such a complex mess its almost next to impossible to pinpoint.

The disconnect would be between the FE and the BE.

 In a normal setup, the FE's have linked table entries pointing to the BE on a "server".  I used quotes on that because it doesn't have to be an actual server OS (but that is best because they are turned for background processing).   Anything that can share a file under windows can be used.   That can be a PC or even a NAS (Network Attached Storage) device.

 With the default database engine (JET/ACE), all the db processing is carried out by each client that connects to the file.   There is no process on the "server" that is executing.   It's just sharing the file.

 and yes, it can be a real headache to figure this out, which is why many use SQL Server for a BE for Access.   With that, there is a server side process which is the only thing that touches the DB file and all requests for data go through it.

  That means if there is a disconnect for any reason, the server process can roll back any transaction in progress and protect the DB.

Jim.

I've resetup the shortcut to point to the correct location and made sure the drive was properly mapped.  I am going to have her test this out and see what happens.

it disconnected again.   this time I opened up access and used the open feature on the program and opened the access db from the network folder rather than using the shortcut to see if it disconnects.

This time it didn't disconnect till almost the end using the open feature from the access program but this time it gave a different error.  Attached is the screen shot
access-error.png

I have ran continuous pings to the server with no packet drops whatsoever on top of this.

It's still some type of a network disconnect for any one of the reasons I gave earlier.

 Also on the ping, for networking you also want to be checking the latency.  Anything over 30ms or 40ms is not good.  One or two here and there is not a problem, but you should see <10 ms on a local network pretty consistently.

 That's why wireless connections are a no go.  With them, you will often see latency of 50 - 60ms.   There doesn't have to be packet loss.

Jim.

I am also wondering if it could be profile related.   I may build her a temp AD account have her login with a brand new profile and see whats happening.   I am also going to address what you mentioned.

Yeah I copied their AD profile and just made a test account.   It will force a new profile in windows and if it still happens we know for sure its the network for sure.

The issue related has been verified as the dbase.   Attached is a screen shot.   They are going to reach out to the DBA to get this fixed thank you for all your help.
Sara-Disconnect.JPG

@Jim the thing is its only 3 people who were getting these disconnect problems, the rest were not.   This is why we assumed it was a network related/ profile related issue and have gone through all the necessary steps you mentioned to troubleshoot the issue and unfortunately did not fix it.   I know our client is eventually migrating to a website design and moving away from local databases so for now we are just trying to keep things up.

We finally heard from the dbase admin here was his answer.

I believe the root problem is Windows 8 and Windows 10 now do asynchronous policy application.  The GPP drive mapping with the option of replace instead of update, which has it's own issues because it doesn't disconnect the drive if the GPP no longer applies, actually disconnects and reconnects the drive as part of GPP application every so often.  Windows 7 didn't do this.
For more info you can see these various articles...
https://community.spiceworks.com/topic/478226-gp-preferences-drive-mapping-with-replace-issue-on-windows-8-1
 
http://community.spiceworks.com/topic/489005-windows-8-1-drive-maps-disappearing
 
https://technet.microsoft.com/en-us/library/cc940895.aspx?f=255&MSPPError=-2147217396
 
http://www.grouppolicy.biz/2013/07/new-background-drive-mappings-in-windows-8-1/
Luckily we're small enough that Update works just fine and seems to have solved the problem so far.

We modified your mapped drive policy which was mentioned as a possible solution and so far it has worked.   Thanks for all the help.