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

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

I am not a novice. I have already posted details of the error. Now today responding to a post below, I have given a fix. And YOU ARE WRONG. Windows 8 has changed how Access works within the changed network because of it's changes. End result - effects Access across the network in certain situations - period - as documented by many. 

You say:

Your turn:

Post a link or email me a sample database zipped up that repeats the network error local (you not done this).

Even if that were possible to send these 6 gigabytes, it would not have duplicated the error. If you were so certain it was a network and not an ACCESS error, you would have wanted network data. I have learned that yes people can be wrong in thinking they have a software error when the have a error in deployment. I have also learned that documentation is lacking to provide adequate detail to understand proper usage. In the post below where I have fixed the error FOR ME, in fact I learned of a utilization of the files related to my front end was the cause, not it's contents, not the network, not access, but which files are opened where. Something changed between earlier version of Access or more likely Windows and Windows 8 that made this a problem when it was not in the past. When I found the correction, I looked thru the documentation and some books to see if It was clearly spelled out - not found - except once slightly in this thread I believe. AND I WILL YELL anytime I want. I believe as stated in prior posts that when one change is made on such a mountain as MICROSOFT,  that an effect elsewhere is not always found or addressed properly and I believe that is exactly what is happening here. You prove me wrong if you like. And you need to have an attitude that reflects the maker's effort is open to the idea they can learn something of their own mistakes and "kindly" ask for help that will find those mistakes if they are yours rather than an attitude the customer is always wrong. One of the things Office 365 has impressed me with thus far is the 180 degree turn on how to approach a problem a customer has - HELP HIM ASAP! THANK YOU 365.