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

Hi

Try the following.

• Create a shortcut to the database in question, by right-clicking on it and selecting "Create Shortcut"
• Edit the shortcut, by Right-Clicking on the Shortcut and selecting "Properties"
• In the "Target" box add the following seperated with a space after the last quotation mark. /decompile
• This would make the target look like this:
• "K:\SOURCING\200 - Data Analysis\Extracts\BW_Extracts.accdb" /decompile
• click apply and run the database from this shortcut.
• Once you have opened the database, run a "Compact and Repair". This is accessed differently dependent on which version of Access you are running. After this you should be able to open the database normally. I have run into this a couple of times, and it is probably down to less than robust network admin, leading to corruption of the file. Hope it helps.

So, halfway to resolving...

The error occurred in the function TablesMatch, which is...

Private Function TablesMatch(strFileName As String) As String

    On Error GoTo ErrorHere

    Dim intFlag As Integer, dbLocal As Database, dbBackEnd As Database

    Dim tdLocal As TableDef, tdBackEnd As TableDef, strReturn As String

    Dim strLocalTableStriped As String

    intFlag = False   ' Initial value, process by exception.

    Set dbLocal = CurrentDb

    Set dbBackEnd = DBEngine(0).OpenDatabase(strFileName)

    Set dbLocal = CurrentDb

    For Each tdLocal In dbLocal.TableDefs   ' Loop through local tables.

        If Len(tdLocal.Connect) > 0 Then    ' This is an attached table.

            For Each tdBackEnd In dbBackEnd.TableDefs    ' Loop thru back-end

                strLocalTableStriped = StripPrefix(tdLocal.SourceTableName)

                strReturn = strLocalTableStriped

                'Debug.Print strLocalTableStriped & " <> " & tdBackEnd.Name

                If strLocalTableStriped = tdBackEnd.Name Then

                    intFlag = True    ' We found a match in back-end.

                    Debug.Print "-- Found it! -- " & tdBackEnd.Name

                    Exit For  ' Jump out for next search.

                End If

            Next

            If intFlag = False Then    ' No match for this attached table.

                TablesMatch = strReturn

                Exit Function

            Else    ' There was a match--continue searching next attachment.

                intFlag = False    ' Reset flag for next table test.

            End If

        End If

    Next

    ' If the function reached here, all tables matched.

    TablesMatch = "OK"

ExitHere:

    Exit Function

ErrorHere:

    Call LogError(Application.CurrentObjectName, "TablesMatch", Err.Number, Err.Description, False)

    Resume ExitHere

End Function

The first time this is called from the function RelinkAccess it reports the first table name rather than the status "OK". So clearly a problem. I removed it from the function RelinkAccess (where it checks if all TablesMatch) and ran the contents of the contents of the IF/THEN/ELSE without confirming that TablesMatch. Everything ran, BUT didn't get all tables. (for my reference it crapped out on T09 WHICH WAS A TABLE THAT HAD BEEN DELETED FROM THE BE, BUT STILL APPEARED IN THE FE). Ran everything a 2nd time AND EVERYHTING WORKED FINE.

So I have been chastised by Microsoft to not shout and to prove it is not the network by getting the same error on a no network setup. Other's smarter than me have proven this. So I am STILL SHOUTING MICROSOFT!

SHOUTING ARE YOU ACTIVE ON RESOLVING THIS ACCESS PROBLEM SOON AS IT HAS GIVEN MILLIONS OF PEOPLE PROBLEMS DAILY AND ENOUGH IS ENOUGH. I WILL CONTINUE TO SHOUT. IT HAS BEEN SINCE WIN7 AND CONTINUES INTO WIN 8.1 AND I BELIEVE HAS A COMPOUND ISSUE SOME RELATED TO THE CHANGES IN NETWORK HANDLING IN WINDOWS AND SOME RELATED TO ACCESS NOT COMPLYING WITH YOUR OWN "IMPROVEMENTS" TO NETWORK ALGORITHMS. 

Maybe if I stop shouting and ask Please, pretty Please?

Ahh bite me. 

I experienced the error described in the previous question, and asked the question including my circumstances. luckily I have resolved it, and have posted full information for anyone that follows.

Just confirming that after deleting the table that existed in the FE (as a linked table) but not in the BE, FROM the FE - Everything worked fine.

Probably not going to help many people, but does show it's not just a network issue...