Solved Your network access was interrupted - due to inactivity?

[The_Doc_Man]

My mistake, initially the network interruption seemed almost regular, but eventually I had it at much more frequent times, including just a 5 minutes or so after signing in.

OK, that is a little bit faster. The question is regularity. If it varies from 5 minutes to an hour then something is going on at another level. It would be appropriate to bring this to the IT staff attention with a question of whether their network load reaches saturation points. These are almost always Ethernet networks so there is a point where at 35% load, there is a sudden rise in the probability of network collisions. When you have such a collision, TWO messages collided and essentially stepped on each other's toes. If the load is sustained for very long, connections WILL time out.

This has to be a gentle question because if the IT staff is facing an overloaded network, THEY are going through crap trying to get approval to change from whatever network speed they have to something faster. I was on a 10 Mbit network with the US Navy many years ago and we had some serious slowdowns, thought Access wasn't involved then. We finally upgraded to 100 Mbit Ethernet and that network flew! Then when we moved to another facility, they installed Gigabit Ethernet and we never had slowdowns. But if you are dealing with older networks, the cost to upgrade includes total recabling to CAT 6 cables and such. So when asking if they are fighting overloads, just be cognizant that if they ARE in that alligator pit, they are fighting tooth and nail to clean up that swamp. Just file one more statistic for them.

 

[kevnaff]

OK, that is a little bit faster. The question is regularity. If it varies from 5 minutes to an hour then something is going on at another level. It would be appropriate to bring this to the IT staff attention with a question of whether their network load reaches saturation points. These are almost always Ethernet networks so there is a point where at 35% load, there is a sudden rise in the probability of network collisions. When you have such a collision, TWO messages collided and essentially stepped on each other's toes. If the load is sustained for very long, connections WILL time out.

This has to be a gentle question because if the IT staff is facing an overloaded network, THEY are going through crap trying to get approval to change from whatever network speed they have to something faster. I was on a 10 Mbit network with the US Navy many years ago and we had some serious slowdowns, thought Access wasn't involved then. We finally upgraded to 100 Mbit Ethernet and that network flew! Then when we moved to another facility, they installed Gigabit Ethernet and we never had slowdowns. But if you are dealing with older networks, the cost to upgrade includes total recabling to CAT 6 cables and such. So when asking if they are fighting overloads, just be cognizant that if they ARE in that alligator pit, they are fighting tooth and nail to clean up that swamp. Just file one more statistic for them.

Hi The Doc Man,

So after 2.5 days on working a 2003 .mdb backend, with people being idle for long periods and even staying logged in through the night, I decided to update the .mdb to .accdb. Within 2 hours of updating, 3 members of staff have had network interruption messages. As I work in a hospital the network has to handle a massive amount of data and cannot tolerate network overloads regularly, as this would cause interruptions within the hospital, which I like to think would be addressed really quickly and even constantly measured to prevent such incidents occurring.

To upgrade to the .accdb, I simply saved and published the existing .mdb file in the latest format. I am now wondering whether importing all of the data in to a new database would help to solve the issue.

If anyone has experience of such an issue please let me know.

Thanks All.

 

[shadow9449]

Thanks, shadow9449, I had forgotten that setting, but it could also have that effect.

Holy cow! a Like from Doc_Man! That's like 10 likes from normal people!

 

[The_Doc_Man]

@kevnaff, there is an old Bugs Bunny cartoon where Elmer Fudd has a recipe for hassenpfeffer, the first instruction of which is to "catch the rabbit." If you cannot catch the rabbit, no hassenpfeffer. The best hope of making headway here is to note an instance of this network interruption and try to get a time of day at which it happens. If you can get a time within a minute, that makes the detective work fairly easy.

Click on the Windows START Icon (lower left on screen, far left of bottom bar.) In the "Search" box type EV and then when it gives you a list of things you could run, select Event Viewer. IF you can open this at all on the machine that experienced the interruption you can perhaps find more info. If even THAT utility is tied down and inaccessible, you are in a really tight situation and debugging this will be quite hard.

When on the control panel of Event Viewer, to the left will be a "navigator" panel that lets you choose which subset of events to view. Network events will PROBABLY be in the System event list. Open that (just click on it once on the navigator panel) and then use up & down arrow to scroll the entries to the time that you determined was the approximate time of the last network hiccup.

It is POSSIBLE (though not very likely) that the Application log could contain the event instead. I doubt that either the Setup log or the Security log will be helpful. However, there is an "Applications and Services" section that if you expand it (click on the > symbol) includes Hardware event logs.

The event logs are ALWAYS presented in order of "most recent event on top" i.e. descending time order - so regardless of which log you are viewing, it should be easy to go through those logs and see if there is a network event logged for that time of day. Your goal, if Event Viewer is allowed, is to find a log of that event.

Note also that if you have the system date/time display in the right-hand side of the task bar (lower right of screen), that is the same clock used by the logging subsystem, so if you noticed the time of day on that clock display, that time should match up with the event log. If you use THAT time, the logged event will be no more than 1 minute either way from the time you noted.

 

[kevnaff]

@kevnaff, there is an old Bugs Bunny cartoon where Elmer Fudd has a recipe for hassenpfeffer, the first instruction of which is to "catch the rabbit." If you cannot catch the rabbit, no hassenpfeffer. The best hope of making headway here is to note an instance of this network interruption and try to get a time of day at which it happens. If you can get a time within a minute, that makes the detective work fairly easy.

Click on the Windows START Icon (lower left on screen, far left of bottom bar.) In the "Search" box type EV and then when it gives you a list of things you could run, select Event Viewer. IF you can open this at all on the machine that experienced the interruption you can perhaps find more info. If even THAT utility is tied down and inaccessible, you are in a really tight situation and debugging this will be quite hard.

When on the control panel of Event Viewer, to the left will be a "navigator" panel that lets you choose which subset of events to view. Network events will PROBABLY be in the System event list. Open that (just click on it once on the navigator panel) and then use up & down arrow to scroll the entries to the time that you determined was the approximate time of the last network hiccup.

It is POSSIBLE (though not very likely) that the Application log could contain the event instead. I doubt that either the Setup log or the Security log will be helpful. However, there is an "Applications and Services" section that if you expand it (click on the > symbol) includes Hardware event logs.

The event logs are ALWAYS presented in order of "most recent event on top" i.e. descending time order - so regardless of which log you are viewing, it should be easy to go through those logs and see if there is a network event logged for that time of day. Your goal, if Event Viewer is allowed, is to find a log of that event.

Note also that if you have the system date/time display in the right-hand side of the task bar (lower right of screen), that is the same clock used by the logging subsystem, so if you noticed the time of day on that clock display, that time should match up with the event log. If you use THAT time, the logged event will be no more than 1 minute either way from the time you noted.

Thanks the doc man.

I've put a request in with the IT department to be given access to the event viewer. So far today, in 8 hours, there have been at least 15 network interruptions. I can't seem to piece together any regular interval between them so far.

I created a test database, with a table containing 3 entries, and a form. Split the database and stored the .accdb and .accde in the same folders our usual database. There was only me connected to the front end, and I got a network interruption message within 90 mins of it being open. I was hoping to identify a regular occurrence with it being idle, but nothing so far. Also as the backend to the test database and the main database were kept in the same folder on the shared drive, and bother were open I was expecting both to get the message at the same time. On the test db the fields on the open record were replaced with something along the lines of NAME.

Hopefully I'll hear back from IT soon and can get to the bottom of this.

 

[kevnaff]

OK so I've just had the IT department access the Event Viewer and they were unable to find anything.

I have just been looking at the folder where my front end is stored, and I still have a copy of the old .mde as well as the new .accde frontend. While I had the .accde frontend open, I'm almost certain that there was no Microsoft Access Record-Locking Information (.laccdb) file open, as I mentioned this to the IT department on the phone.

I then opened the old .mde frontend and login, and this then opened a Microsoft Access Record-Locking Information (.ldb) file.

Could it be the issue that the .laccdb is disconnecting and therefore the network interruption message is showing as it can no longer access the backend?

Does the .laccdb provide access to the back end or is it just there to prevent duplicate primary key IDs being entered?

 

[The_Doc_Man]

If the .ACCDB file is opened in Exclusive Mode it does not open a lock file. Did you INTEND to open it exclusively?

 

[kevnaff]

If the .ACCDB file is opened in Exclusive Mode it does not open a lock file. Did you INTEND to open it exclusively?

I did not intend to open it exclusively. I am 99% certain that a lock file was not created when I was inside the database. I just opened it as normal.

How easy is it to open it exclusively?

We are all accessing the database through a shortcut that I created which contains the following path:

"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE" \\***\home\%USERNAME%\Med2k\Application\Med2kSApp.accde /Excl /Wrkgrp "\\***\GROUPS\Medical Engineering\Med2k\Shared\System.mdw"

 

[kevnaff]

Another Finding.

My .accde file has a gold padlock on it, that looks like this..

My colleague has a blue padlock on it, that looks like this... ignore the locking file beneath it, this is from the old .mde file.

From my experience when I opened the .mde, the .mde did not have a padlock, but it would open a locking file that would have a padlock on it, like this below

 

[techiejunk06]

I tend to use a public variable to store the user name but that's personal preference. A tempvar should work equally well.

 

[The_Doc_Man]

How easy is it to open it exclusively?

Three ways, 2 of which are "set and forget"

1. When the file opened in any version of Access that has a ribbon (after AC 2003 ?), use File >> Options >> Current Database and go through the list of options you can set. One of them is "Open Exclusively" which will remain set until you change it.

2. From a command line activation, use /EXCL opton

Command-line switches for Microsoft Office products - Microsoft Support

Use command-line switches to customize the startup process for Microsott Office programs: Word, Excel, PowerPoint, Outlook, and Access.

support.microsoft.com

3, Edit the icon for your application (NOT FOR ACCESS ITSELF) to include the /EXCL option.

 

[kevnaff]

Three ways, 2 of which are "set and forget"

1. When the file opened in any version of Access that has a ribbon (after AC 2003 ?), use File >> Options >> Current Database and go through the list of options you can set. One of them is "Open Exclusively" which will remain set until you change it.

2. From a command line activation, use /EXCL opton

Command-line switches for Microsoft Office products - Microsoft Support

Use command-line switches to customize the startup process for Microsott Office programs: Word, Excel, PowerPoint, Outlook, and Access.

support.microsoft.com

3, Edit the icon for your application (NOT FOR ACCESS ITSELF) to include the /EXCL option.

Hi The_Doc_Man,

The frontend has always been distributed with the shared mode option selected, however, the shortcut that we have always used for our frontend .mde file uses the following path:

"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE" \\***\home\%USERNAME%\Med2k\Application\Med2kSApp.mde /Excl /Wrkgrp "\\***\GROUPS\Medical Engineering\Med2k\Shared\System.mdw"

Does this mean that the database has always been opened exclusively by each user as it contains the /Excl option?

I have always thought that this path meant that the database is opened exclusively to those in the workgroup file which follows it, but it seems that's not the case.

 

[The_Doc_Man]

Does this mean that the database has always been opened exclusively by each user as it contains the /Excl option?

I would answer this as "most likely, yes." If your users ever tried to open the DB simultaneously through the shortcut, whoever came in other than 1st in the attempt SHOULD have gotten a "database is in use opened exclusively" or something to that effect. (Don't recall the exact message at the moment.)

When I listed methods of opening exclusively, I forgot about another way. Open Access directly without a named app, then browse to select the file to open, then open it using a drop-down from the Access browser dialog (rather than from your app) that says Open Exclusively. Also pretty easy. This "browse through Access" method would also allow you to Open Shared even if the app was marked Open Exclusively.

How to Open Access Database Exclusively (2007-2016)

www.cocosenor.com

 

[kevnaff]

Hi All.

To link my tables to the backend, I was using the linked table manager to select the new location, which was opening a file browser for me to link to the backend. This meant that my filepath to the backend was G:\Engineering\Database\Backend.accdb

The issue was solved by manually typing in to the file browser box the full location of the file, including I assume the server first. This meant that the file path turned in to \\trust\groups\engineering\database\backend.accdb

As I mentioned, with the 2003 .mdb format the file path did not seem to matter. As soon as I updated the file format to 2010 .accdb that is when the issues occurred for me.

Since switching over 3 days ago I haven't had a single network interruption message, whereas my users were getting one at least every hour or so previously.

Thanks so much for all of your help, I've learnt a lot.

 

[Minty]

That would imply that the users are losing the mapped drive randomly.
The UNC path wouldn't suffer from that. It's a really interesting observation.

Generally, on here we have always recommended UNC paths for use in Access but not specifically for back end data paths.

 

[Gasman]

https://docs.microsoft.com/en-us/tr...mapped-drive-connection-to-network-share-lost

https://support.microsoft.com/en-us/topic/2b693418-fb80-1149-7034-78af6e6847ba

 

[gemma-the-husky]

Holy cow! a Like from Doc_Man! That's like 10 likes from normal people!

It's a real good spot though. Because we work in Access, the immediate assumption is that any problem is an access problem, and it's not necessarily the case. Another example is processor affinity.