Solved Your network access was interrupted - due to inactivity?

[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.