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

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.

I believe there may be a few reasons this internet error occurs. Here is what has resolved it for me for the last few months. It has been a long process in some ways but a simple unknown fact helped:

In my study and research somewhere, probably within this thread it was mentioned that each user must be opening their own separate copy of the front end. I had on my server ONE copy of the ACCDB file and an ACCDR and an ACCDE file but simply one of each for accessing the front end and it was located on the server in the same folder as all the back end files. Once I learned the knowledge that each user should use their own front end file copy, I copied the appropriate file to the desktop of each machine - one using a runtime Access package ( no longer) and the other machines using a copy of the compiled accde file except when I was making design changes to the front end where I would open the server based accdb file and then re-deploy the files to each desktop.  This effectively stopped all network errors.

In the mean time, the many forms and reports and tables etc within the front end had developed errors from the internet interruptions. I went thru every one and fixed errors which were most often a form which had lost it's data source and reverted to the recognizable table rather than the built in query type data and sort set up with the form properties settings. All damaged forms had a new parameter pop up box and usually gave a clue to the unbound object. One form will not longer save and will have to be redesigned. I have run in to this before mostly on tabbed forms where the design changes can be made, the form can be saved as far as detectable till you reopen in design and see that actually the changes were not saved. 

Now to simplify the process of propagating the changes to the front end, I tried One Drive for business, but one machine remains unattached to our one drive for business. I tried One Drive ( Hotmail) and that was complicated for various users. I tried Google Drive and was not able to easily do that do to multiple accounts. I then went back to basics.

I created a "LANShare" folder on every hard drive and shared it with the LAN / Homegroup. I then at the server mapped those shared folders so the server can write by a simple drive letter. I then created a batch file and one simple click writes the current file on the server to each machine in the batch file.

Here is the batch file I used which has my specific folder details and of course you need to change for your setup:

cd C:\WORKING\Repair\Access

copy /y /V C:\Working\Repair\Access\Repair2007.accde x:

copy /y /V C:\Working\Repair\Access\Repair2007.accde w:

copy /y /V C:\Working\Repair\Access\Repair2007.accde V:

copy /y /V C:\Working\Repair\Access\Repair2007.accde C:\LANShare\Repair2007.accde

x, w, and v are the mapped drive numbers of the remote lan pc's on the server. and the last line is to insure at the server when using the database, it to is using it's own file.

You have not done batch files?

copy this into the notebook editor and edit your source and destinations and save it as a .bat file. Then run it. to get help with batch files, in the cmd window type help.

Hope this resolves the issue for those of you still dealing with it. Nothing else in this thread "resolved" it for me but some reduced the incidence of errors.

There are, I am sure, many ways to disseminate a copy of the front end file for each user to execute it's own copy and a better way for any novice will be looked at by me, so fire away!

Compact and Repair worked for me and usually does with most Access problems

Please note, there is an issue and it is Access and Windows beyond XP ( as this error did not ever occur in XP w/o version 6 tcpip). the following is not proof but yet another tid bit I have learned over 3-4 different routers, 5-6 pc's, 3 different version of access, 2 different versions of Windows( post XP! ), and the fact it did not occur prior to Windows 7,8,8.1.

The frequency of the network error increases over time once it begins. Once it begins, and I have the time, I shut down all access to Access, go in and compact and repair each of the 12 database files ( one front end, 11 back ends linked,  smallest 70k, largest 877,000K ). I have over time set up tcip version 6 as available, and not available. This seems to have less problems in recent times using version 6 but when I first started using Windows 8, it failed multiple times per day, so I set all items on the LAN to not use version 6. With nearly daily updates from MIcrosoft, I suspect an update has made version 6 more reliable and a LAN crash/crack/problem effecting database files has been much alleviated. Today, I see this error very seldom, but it does happen now and then and as soon as possible -go thru compact and repair each related file and breeze on.

So, It ain't Rocket Science, It's it's beyond that. I am not a team to resolve it, that is why I BUY from Microsoft, the biggest team, but sometimes so big they can't identify how one fix fixes another, and sometimes one fix messes up another. Don't get me wrong, the first place I look for what I need is MS, we were born together, although my first purchased computer was a Tandy Color Computer and the first computer I worked on was 7 feet tall IBM 4k memory with a card reader, and that ain't a credit card reader for you younger people! It was also a step up from that 4K monster to a digital/ octal ferrite core 32k with front panel switch stepping programing in Octal code.

I have had this message during an attempt to compact my accdb file, located on my home drive (network). However, I tried compacting again copying the accdb locally and it worked fine. I found that the quota on the home drive left was not enough capacity to hold temp fies created during comacting, I am suspecting.

So seems that a disk space issue can cause this message to appear, however, it's very misleading in such circumstances.

Hope that helps.