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

You shouting is based on lack of basic computer skills and understanding of how computers work.

The problem is no one here can re-produce your issue. Post a link to a database that re-peats this issue as you claim on a local drive. You simply failed to do this and cannot no. Examples with deleted linked tables is a rather silly example.

You are assuming that access has some “new” change in regards to networking and it not the case. How Access works has not changed in regards to networks in MANY years.

The simple fact is you NOT running ANY OTHER file based system that requires the file open connection remain open at all times OVER a network, and ALSO support mutli-user mode. What other applications do you have that fits this criteria? (Answer: none). So this explains why other applications don't have this issue (but also explains you not grasping the difference here either).;

As noted in this thread, near 100% of the posters have been able to RESOLVE THIS ISSUE and you stand rather ALONE as this being a problem WITHOUT reason.

The BIG tip off is the one poster stating that this occurs when the laptop lid is closed. No kidding! The key change in later editions of windows is power management.

Windows 7 and 8 has MUCH better power management and are able to power-manage (turn off) things like network cards etc. to save power. When such power options occur, then you broke the network connection. So power management is another area I would look into.

And your claim of a sample database that causes this error on a local setup has not occurred to any reasoned and competent satisfaction. You will find rather fast that few will listen to you until such time you post a working example of this issue being repeatable on a local machine, or retract this claim.

The VAST majority of people are not having this issue. Those having this issue in most cases have solved this problem. As noted in most cases it simply the client computer turning off or breaking the connection. The other issue is bad network (switch or otherwise). Issues such as Power management or simply closing the lid on the client computer are near tops for this issue. This is NOT the fault of Access NOR has some change been made.

If you use Access OVER a network connection then that connection MUST remain open – it is a basic requirement of a multi-user file based system. I would suggest you disable all power management on any client computer you test with, and specifically the network card power management.

At the end of the day, based on the information you given, you have MAJOR failed to show this some special problem related to Access beyond anything that this community has not been aware of for 18 years!

And you not posted a working example that fails local, and again until such time you beating a dead horse here.

Post a working sample, or zip it up and email it to me. If the code fails on my computer then you have a case – until then your just venting hot air and you stand VERY ALONE in thinking that Access has some bug or problem here. And worse your cries will fall on deaf ears until you show a working example of this issue. And you cannot convince me, then you really in trouble.

Few if anyone is listing to you because you have in a speculator way failed to convince anyone here of some special issue and you also failed to convince me.

There are MANY reasons for a break in network connections – whatever those reasons are the SIMPLE long term fact is Access does not and never did tolerate breaks in the network connections.

Your turn:

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

I onsficatined my email address, but you should easy figure it out.

Best regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada

PleaseNoSpam_******@msn.com

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.

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.

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

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!