SOLUTION TO ERROR " Your network access was interrupted. To continue close the database and then open it again." __

While this thread makes for interesting reading it doesn't really help.

We have upgraded the OS and access over the last few years from Access 2002 and Vista, through Access 2007 and windows 7 to the latest Access 2013 and 8.1.

It is only this last upgrade from windows 7 to 8.1 that we are now experiencing this message, therefore I can only surmise the issue is the 8.1 upgrade and how it handles inactive network connections.

However other programs (non MS eg MYOB) don’t seem to have the same network issue and can be inactive for several hours without timing out.

So I have several questions:

1. How do we change the way 8.1 handles inactive connections to leave them open?
2. If non MS programmes can override this and keep the network open are we able to get access to do the same?

I’m not sure if this question is posted in the correct place however I look forward to any help you can supply.

After recently running into this issue the solution i found was as follows:

After a server crash and subsequent db move to a new server, a cname record had been created for the old server and new share for the db created on a different server.

From this time on Win7 machines were fine accessing the dbase but XP failed with the connection interrupted message.

The clients were actually unable to access the UNC path based on the CNAME record, returning a message of duplicate name found... Turns out that XP and 2008R2 does not fully communicate perfectly without issues.... no surprises with the age difference.

The 2008 Server needed to have a few mods made to allow it to accept incoming connections based on the CNAME record, this fixed the network interruption issues on the XP clients, details here:

http://www.wincert.net/tips/networking/1767-duplicate-name-exists-on-the-network-when-using-dns-alias

So yes in my case it was a communication issue but no it was not an issue with the network itself.... I know its not a fix for everyone here but it might help someone.

The problem here is that network traffic can be disrupted. This is a fact of life. Even the most modern and powerful of networks can suffer a blip in transmission. As Windows and Access has progressed, they have both become more sensitive to these blips. This is for your protection! It protects your data from corruption. But it is annoying. It is part of the reason we recommend split databases with local front ends. 

The answer is to clean up your network to reduce the blips. Nothing you do in Access (other than split them with a local front end) will solve this problem.

However, as I stated, I not aware of a change to Access here.

And as noted, for the last 15 years, it been recommended that you install your applications on each desktop. You install Word on each desktop. You install Excel on each computer. So now that YOU ARE creating software (you know, with code + UI), then such code AGAIN needs to be installed on each desktop.

I am done here. You simply do not know the difference between a back end and a front end in Access versus the Software package "Access"  so I won't waste any more words and suggest your feedback null and void. Good Day sir.

Don't like this kind of feedback, I did not like yours which came from your back end, not that you know where or what that is.

The PROBLEM IS YOU ARE claiming this is an access problem and specifically a new one. So buck up the beef and show me this!

It is YOU that must provide and prove your position. So simply provide an example that this error is re-producible with Access. Now you stating this is a network change.

It "was" YOUR claim this is a NEW problem with Access or some change in the Access product.

Why would I ask you to provide evidence NOT related to your claim? Not looking or worried about what I already know about networks – not the claim being made here.

I am asking for YOUR witness and testimony, and asking YOU to provide such evidence.

It is YOUR claim in public that this is an Access problem. If this is an access problem, then I going to ask for a re-production via access example. Really rather simple.

As I stated, changes in networks that can cause a drop in the network is simply a change in the network. I mean, really, the sky is blue, 2 + 2 = 4, and there been some news that many changes and additions have been made to windows networking has occurred? (no kidding!). As I stated, in most cases these changes are power management. But there also new network stacks, and now IP6 etc.

However, as I stated, I not aware of a change to Access here.

And as noted, for the last 15 years, it been recommended that you install your applications on each desktop. You install Word on each desktop. You install Excel on each computer. So now that YOU ARE creating software (you know, with code + UI), then such code AGAIN needs to be installed on each desktop.

Why single out your application and not install it on each desktop? Word, Excel, or you “great” application you built can certainly consume files (data) sitting on the server, but you installed everything else on each desktop, so why not your software? Please explain?

So you been installing all other software on each computer – why not the same for your application?

I don’t see any articles or suggestions in my owners manual to not drive my car backwards, but basic competency and knowledge is required to drive a car.

The basic issue and claim here was that Access changed, and something “new” has arose in the product that cases this network error. And my answer is no, that is simply not the case, and you provided nothing that changes the use case of Access in this regards.

And in regards to changes to networks? There have been TONS of changes, but the means and how Access works over those networks has NOT changed. In fact there is  ZERO witness and testimony from the Access community that such a change to these networks in equal comparisons has changed or reduced the network conneciton issue.

So the daily repeated advice to run software on each desktop is something I willing to bet that even YOUR company does, has been doing for years, and you likly the ONLY one that went against this long time practice in our industry.

Keep in mind, that when writing code you are now creating software. This is signficaltly diffent then a "documents" form excel or word, or some table data. Such software needs to be installed on each computer.

Regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada