Your network access was interrupted - due to inactivity? (1 Viewer)

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
Hello All.

So I've updated my .mdb files and .mde files up to accdb and accde files. Since upgrading them, renaming them and making a few design changes, several users are getting a 'Your network access was interrupted' message on their split front end. I have read that this can be due to inactivity and there being a network drop during this inactivity, however it's happening quite frequently, maybe once an hour. In the past, if a user stayed logged in overnight, this could cause a similar message to appear but never for such a short period of time.

Each user will always have a Home Page open. Is it possible to have some code running in the background that will update every minute or so that can keep this connection alive to avoid a network dropout?

It could just be possible that the network is not functioning properly at the moment, but it's hard to get an update on the status of the network from our IT department.

Thanks
 

isladogs

CID VIP
Local time
Today, 09:33
Joined
Jan 14, 2017
Messages
15,244
The easiest method is to use a persistent connection to the backend database.
At startup, open a hidden form which uses a small linked table as its record source. Ideally this should be one field & one record only to minimise its impact.
Keep that form open in the background whilst your app is running.
This not only ensures the connection isn't dropped, it will improve performance as Access won't need to re-establish the connection each time you make use of any linked table.

If that doesn't solve the problem, then there is a n issue with your network dropping out intermittently
 

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
The easiest method is to use a persistent connection to the backend database.
At startup, open a hidden form which uses a small linked table as its record source. Ideally this should be one field & one record only to minimise its impact.
Keep that form open in the background whilst your app is running.
This not only ensures the connection isn't dropped, it will improve performance as Access won't need to re-establish the connection each time you make use of any linked table.

If that doesn't solve the problem, then there is a n issue with your network dropping out intermittently

Thanks Isladogs.

I have created a table called persistent connection with 1 record and 1 field. I have added the following code to the Login button which opens thes databases main page:


Code:
DoCmd.OpenForm "Persistent Connection"


Forms![Persistent Connection].Visible = False

I'll give this a go, hopefully this solves the issue. Also, great that it can improve performance as several queries take a long time to open.
 

isladogs

CID VIP
Local time
Today, 09:33
Joined
Jan 14, 2017
Messages
15,244
Just to check that it is a linked BE table...
Also suggest that you don't use spaces in object names or field names
 

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
Just to check that it is a linked BE table...
Also suggest that you don't use spaces in object names or field names

Hi Isla,

Below is a picture of the table. When hovering it does show a link to the back end table on the shared drive.

1631622653087.png



Would the spaces cause a network disruption?

The only thing that is completely different between the new changes and the old is that we used to login using a system .mdw file. Many of the fields in the tables used to used the [current user] that was taken from the .mdw login. As this feature isn't available in Office 365 which we are soon to upgrade to, I changed the anything relating to [current user] and updated it to [TempVars]![tvarUser].

The [TempVars]![tvarUser] is taken from when the user logs in. Whenever a user updates a record, it will keep a record of the user using [TempVars]![tvarUser] and also a record of the current date and time using Now().

Has anybody had issues using the [TempVars]![tvarUser] function?
 

isladogs

CID VIP
Local time
Today, 09:33
Joined
Jan 14, 2017
Messages
15,244
Using spaces is bad practice but isn't responsible for network interruptions.

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

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
Using spaces is bad practice but isn't responsible for network interruptions.

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


That's good to know.

Unfortunately the non-visible form has not fixed the network issue. This is the first time I've consistently had this issue in the 15 months or so of managing the database, and has only occurred since I implemented the new design features. Unless there's a big coincidence that there are problems with the network in the last 2 days since I've updated, then I need to look at why this has happened.

Any advice would be greatly appreciated.

Thanks
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:33
Joined
Feb 28, 2001
Messages
20,629
Things happening on the order of once per hours are too common for it to be an accident. Typically for frequent session drops, your problem isn't Access itself but a per-system network setting called a "keep-alive" timer. However, there might also be issues in something called a "Group Policy" download that would come from the Domain Controller on your network. You would need to ask the IT staff what, if any, group policies get downloaded on each login and whether they impose an "idle-session" limit, which would be done at the Windows level, not the Access level. If it is a Group Policy issue, you might have a political fight on your hands.

I also have to say this: It is probably a questionable OPERATIONAL design (not a technical issue) to suggest or allow leaving an idle DB application open overnight. The problem in a nutshell is OPPORTUNITY in two parts.

(1) Leaving an open DB app means your system has to stay logged in to the domain AND your screen, if not locked, is a window into your DB's content. From a security viewpoint, these are things that current Windows trends try to control. That open app offers an opportunity for someone to meddle, steal things, or plant incorrect/false data.

(2) There is the purely technical opportunity for a problem to occur. The probability of having a network drop during a session goes up the longer the session lasts because if you have X% per hour of experiencing a network drop, that probability is additive. If your session lasts 2 hours you have 2X% chance of a drop. 3 hours, 3X% and so on. If you have a 1% chance per hour of a network drop and your session could last 4 days, you have a 96% chance of having that drop. (Don't wait four more hours....)

Now... a way to do something to help the session stay alive? Having the open connection SHOULD help - but if it is caused by network inactivity and the connection's KeepAlive setting isn't helping, set up a timer on that invisible form that manages your persistent connection. You said there is a field in the table. Add a Yes/No field to that table. Once every so often, certainly not more often than once every 20 seconds, do this:

Code:
CurrentDB.Execute "UPDATE [PersistentConnection] SET ToggleField = NOT ToggleField ;"

If the passive KeepAlive settings don't keep it alive, then do something active every 29 1/2 seconds. Set the form's timer to 29500 - because typically such "session idle" settings are 30 seconds. Run that command from the Form_Timer event. That network activity might "fool" the Windows-based internal facility that is dropping your sessions.

IF this does not work either, then your problem is probably outside of Windows - somewhere in the network at the physical-link, point-to-point, end-to-end, or session layers. That WILL require assistance from your network managers.

I know this post went all over the place, but I think it covers a lot of the possibilities.
 

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
Things happening on the order of once per hours are too common for it to be an accident. Typically for frequent session drops, your problem isn't Access itself but a per-system network setting called a "keep-alive" timer. However, there might also be issues in something called a "Group Policy" download that would come from the Domain Controller on your network. You would need to ask the IT staff what, if any, group policies get downloaded on each login and whether they impose an "idle-session" limit, which would be done at the Windows level, not the Access level. If it is a Group Policy issue, you might have a political fight on your hands.

I also have to say this: It is probably a questionable OPERATIONAL design (not a technical issue) to suggest or allow leaving an idle DB application open overnight. The problem in a nutshell is OPPORTUNITY in two parts.

(1) Leaving an open DB app means your system has to stay logged in to the domain AND your screen, if not locked, is a window into your DB's content. From a security viewpoint, these are things that current Windows trends try to control. That open app offers an opportunity for someone to meddle, steal things, or plant incorrect/false data.

(2) There is the purely technical opportunity for a problem to occur. The probability of having a network drop during a session goes up the longer the session lasts because if you have X% per hour of experiencing a network drop, that probability is additive. If your session lasts 2 hours you have 2X% chance of a drop. 3 hours, 3X% and so on. If you have a 1% chance per hour of a network drop and your session could last 4 days, you have a 96% chance of having that drop. (Don't wait four more hours....)

Now... a way to do something to help the session stay alive? Having the open connection SHOULD help - but if it is caused by network inactivity and the connection's KeepAlive setting isn't helping, set up a timer on that invisible form that manages your persistent connection. You said there is a field in the table. Add a Yes/No field to that table. Once every so often, certainly not more often than once every 20 seconds, do this:

Code:
CurrentDB.Execute "UPDATE [PersistentConnection] SET ToggleField = NOT ToggleField ;"

If the passive KeepAlive settings don't keep it alive, then do something active every 29 1/2 seconds. Set the form's timer to 29500 - because typically such "session idle" settings are 30 seconds. Run that command from the Form_Timer event. That network activity might "fool" the Windows-based internal facility that is dropping your sessions.

IF this does not work either, then your problem is probably outside of Windows - somewhere in the network at the physical-link, point-to-point, end-to-end, or session layers. That WILL require assistance from your network managers.

I know this post went all over the place, but I think it covers a lot of the possibilities.

Thanks The Doc Man, great advice.

I will implement this and see how it goes.

Users are always asked to log out of their DB when leaving for the day, but this isn't always followed. I may look to implement an auto sign out feature in the future, but for now I will try what you said.

Hopefully this solves it!
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 04:33
Joined
Feb 19, 2002
Messages
32,787
I would lean toward some network change or perhaps hardware failure. You can do the things that Doc suggested but I think something happened recently that made the network unstable. Access is like the canary in the coal mine when it comes to unstable networks which is why we always recommend a hard-wired network rather than a wireless one. Wireless networks drop connections much more frequently than wired ones do and Access cannot gracefully recover from a network blip.
 

isladogs

CID VIP
Local time
Today, 09:33
Joined
Jan 14, 2017
Messages
15,244
Pat has raised a very important point. Are any of your users connecting to the network using WiFi ?
 

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
I would lean toward some network change or perhaps hardware failure. You can do the things that Doc suggested but I think something happened recently that made the network unstable. Access is like the canary in the coal mine when it comes to unstable networks which is why we always recommend a hard-wired network rather than a wireless one. Wireless networks drop connections much more frequently than wired ones do and Access cannot gracefully recover from a network blip.

Hi Pat. Thanks for the advice.

All PCs have wired connections to the hospital's network, which then connects to the back end on the shared drive.

The system has been stable for 20+ years despite a few hiccups. I have solely been in charge of the system for 18 months or so, and it has only been in the last 2 days since updating the .mdb and .mde files to accdb and accde files, that I've had this issue. The hospital will soon be upgrading to Office 365 which will not support our system .mdw file which we use to login. Quite a few features in the database make use of the [current user] that it takes from the logged in user from the .mdw file. To prepare for this, I have created a new login screen and now take the current user using [TempVars]![tvarUser] from the user's username when they login. Between these 2 steps I believe there may be an issue.

All will be revealed tomorrow whether the 29.5 second persistent connection update has worked, when everybody is back online and using the system at the same time. Fingers crossed
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 04:33
Joined
Feb 19, 2002
Messages
32,787
Strange coincidence. Not sure how your users are using an .accdb with an old version of Access though. Hope the persistent connection solves the problem.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:33
Joined
Feb 28, 2001
Messages
20,629
If this is a hospital, I would find it seriously hard to believe that the IT staff members have NOT implemented a domain structure and have also implemented network security to include Group Policy issues. Your IP addresses come from Liverpool; Camden; and Sofia, Bulgaria (?). You don't have the USA HIPAA laws but I wouldn't doubt that the UK has something similar. Therefore, my question is, has anyone from your network team announced new protocols related to implementation of the European security changes?

As to your login, if you can't use the .MDW file any more, but have a secured domain, there are ways to identify the users by trusting the domain login. Isladogs has posted lots of stuff relating to using the domain's network login name for the user. At worst, this might mean a lookup table to convert the network login name to the name used in the .MDW file.
 

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
Strange coincidence. Not sure how your users are using an .accdb with an old version of Access though. Hope the persistent connection solves the problem.

Hi Pat, we're using Office 2010. I have reverted back to the .mdb and .mde as I had another network interruption message this morning. If everything is stable by the end of tomorrow, I will add in the new design changes that I made to the .accdb, but keep the file type as .mdb, and see if this works OK. If so then I will upgrade to .accdb and .accde and see how it goes.

Thanks for all your help.
 

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
If this is a hospital, I would find it seriously hard to believe that the IT staff members have NOT implemented a domain structure and have also implemented network security to include Group Policy issues. Your IP addresses come from Liverpool; Camden; and Sofia, Bulgaria (?). You don't have the USA HIPAA laws but I wouldn't doubt that the UK has something similar. Therefore, my question is, has anyone from your network team announced new protocols related to implementation of the European security changes?

As to your login, if you can't use the .MDW file any more, but have a secured domain, there are ways to identify the users by trusting the domain login. Isladogs has posted lots of stuff relating to using the domain's network login name for the user. At worst, this might mean a lookup table to convert the network login name to the name used in the .MDW file.

Hi The Doc Man,

Our IT team do implement group policies, but I'm not too familiar with them or how they affect our group of workers.

The database doesn't contain any patient data, so we tend to get left alone due to the fact there's no sensitive information in our database.

The old .mdb and .mde files have been running completely fine for 3 hours now, which gives me time to sort the issues out.

Thanks for your advice
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:33
Joined
Feb 28, 2001
Messages
20,629
Our IT team do implement group policies, but I'm not too familiar with them or how they affect our group of workers.

Group policies can be used to implement session time-out events. The situation of having an hour before getting tapped out is too frequent and too regular for it to NOT be an internal timer. By this I mean that "one hour" is too even a number for this to be a random event. Now if you said it happened at 47 minutes or 51 minutes or 73 minutes at different times, that begins to sound random and would perhaps be intermittent hardware issues. But an hour every time is by design.
 

shadow9449

Registered User.
Local time
Today, 04:33
Joined
Mar 5, 2004
Messages
1,020
A few comments:

- I always use .mdb and I've had a few clients complain that they receive "your network access was interrrupted", even while working on the system. I always use a persistent connection in split databases. So, I don't think that it makes a difference which file format you are using.
- As far as timing out due to inactivity, one place to look is from the Device Manager, select the network card and click the Power Management tab and see if it's set to Allow the Computer to turn off the device to save power. This is a pretty common setting that I've found can cause a real hassle.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:33
Joined
Feb 28, 2001
Messages
20,629
Thanks, shadow9449, I had forgotten that setting, but it could also have that effect.
 

kevnaff

Member
Local time
Today, 09:33
Joined
Mar 25, 2021
Messages
53
Group policies can be used to implement session time-out events. The situation of having an hour before getting tapped out is too frequent and too regular for it to NOT be an internal timer. By this I mean that "one hour" is too even a number for this to be a random event. Now if you said it happened at 47 minutes or 51 minutes or 73 minutes at different times, that begins to sound random and would perhaps be intermittent hardware issues. But an hour every time is by design.

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

A few comments:

- I always use .mdb and I've had a few clients complain that they receive "your network access was interrrupted", even while working on the system. I always use a persistent connection in split databases. So, I don't think that it makes a difference which file format you are using.
- As far as timing out due to inactivity, one place to look is from the Device Manager, select the network card and click the Power Management tab and see if it's set to Allow the Computer to turn off the device to save power. This is a pretty common setting that I've found can cause a real hassle.

Hi shadow

I will implement the persistent connection on my .mdb for now.

Unfortunately my admin rights are completely limited meaning I can't even open the Device Manager, they're very strict about security with it being a hospital. Our computers are locked out after a period of inactivity of usually around 15 minutes. I will try and get some answers regarding the Power Management if my issues come back.

Thanks both for your help.
 

Users who are viewing this thread

Top Bottom