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

Hi @All

I have experience the same issue on Win server 2008 / Terminal Server.

We use an access database since 2003, based on the network (DFS).

Since last week (10th of Septembre), I got that issue.

I tried to compact / repair : no change.

I copied the database : works

I changed it to the original  name : doesn't work

Run the access from Desktop / laptop / other Terminal server : it works

I had to reboot the Terminal server ... but today, it comes again ... sic !

I first thought that KB3076895  was the reason.

I installed last week the KB3092627 to correct it ... Both are installed correctly.

I must reboot again now and check if it works.

I'm pretty sure that a Patch is the root cause. But, unfortunately, the issue doesn't come after reboot ... and so playing with patchs is not reliable to know if it solves or not ...

Please share your experience and  why not the solution you have found ...

Thanks in advance ...

I am not a system administrator just an end user. However, your above comment is not correct. I get this error on many different access databases. However, many times you are not allowed to close the database and reopen. You have to completely reboot the entire computer in order to reopen that access database. If you were working on a new query or macro then it is completely lost and you have to start again. This happens multiple times a week and multiples times on some days. There is no rhyme or reason to when it will happen. My IT guys have been unable to provide me with any help as they see no network issues. I am also not able to compact my databases as I have always been able to do. This issue started happening today shortly after getting the interrupted network message. I have rebooted twice today and continue to have issues with Access.

I have started to experience this problem at a client and it is embarrassing.

Let me explain how my procedure works.

When my access front-end launches from the client computer the first thing it does is check the data tables to see if they are linked.

I do this by running through the table definitions and comparing them to tables that should be on the back-end on the server. (See Code)  

******************************************************************************************

For Each tdf In db.TableDefs

        'If connect is blank, its not an Linked table

        If Len(tdf.Connect) > 0 Then

            'Debug.Print tdf.Name

            'Check to see if it is a data table

            sSQL = "SELECT * FROM tblSystemTables WHERE Location = 'DATA' AND TableName='" & tdf.Name & "'"

            Set rs = CurrentDb.OpenRecordset(sSQL)

            If Not rs.EOF Then

                tdf.Connect = ";DATABASE=" & sDataLoc

                ' The RefreshLink might fail if the new path

                ' isn't OK. So trap errors inline.

                On Error Resume Next

                    tdf.RefreshLink

                    'If one link bad ...

                    If Err <> 0 Then

                         iErrCnt = iErrCnt + 1

                         Debug.Print tdf.Name; " Not Found"

                    End If

                On Error GoTo 0

            End If

            rs.Close

        End If

        varReturn = SysCmd(acSysCmdUpdateMeter, intI + 1)

    Next tdf

****************************************************************************************************

Now in troubleshooting this I discovered that the initial attempt to access a linked table was refused.  This of course caused my error count to increase making my program assume the data was not available.  My procedure when this happens is to request new information from the user using an open dialog box to determine the back-end's new location.

I found however that the linked tables were in fact properly linked.  And when I attempted to re-link them I could not verify they were linked properly.  Then I tried just canceling out of my dialog box and the database bypassed the relink and opened properly.

I instructed the users to just hit cancel and that the problem was in work.

After typing this I think I will loop the table link and check each table 3 times.  if it fails 3 times then record it as a failure.  If it passes at least once record it as good and move on.

This only happens on one client's network.  I have no control over the network administration.  And if I were in their position I would not take this as a network problem either.  I do believe it is network related and access/win 7 related.  As they say at NASA, it is not one event that causes a catastrophe but a number of events that accumulate into a disaster.

if useing with link tables and bounded controls in LAN environment especially for multi clients than 3, This problem will occur some time similar to trying to open a text file whose handle has been used and not free. So connect the back end database as soon as possible, and disconnect it after retrieve data like asp web will reduce this problem to happen.

If moving the file makes this works, then VERY likely this is a network permissions, or someone else on the network has (or had) the file open, and experienced a problem.

So the “reason” why you cannot open the file in that location is become someone else on the system (even a computer that crashed) likely still has some open file handles “attached” to that file.

Thus some locks are holding that file name. You likely need to re-boot the server, or get the server admin to “remove” any users that have that file location open (the admin can also check and see who has the file open and THEN force close the files open by that those other users. So have the admin do that for this file + location. So the location cannot be now used because either you or someone else has the file open and locked (I would also check if your accident running more then one copy of mms-access – check your task manager).

There is really no other reasons as to why you cannot open + use the file in a particular folder that worked before. The other possible reason of course is folder and file permissions. In some cases the folder (or the database file) may be inheriting permissions from particular users – this can have an effect on other users who attempt to use + open files in that folder (and in fact who even copies the file - say plugging in a jump drive into the computer were the folder resides - now that file has permissined attached to the ONE user).

And another common case is when a user opens the back end file, then a locking file is ALSO created. In some cases that locking file inherits permissions from that particular user (who created the locking file) – the result is other users cannot open the back end (or usually they become “read only” and cannot update data).  And same goes if users don't have create rights in that folder.

And the same goes if a compact + repair is done – this actually causes a NEW copy of the file to be created and AGAIN this can mean that the file now has permissions limited to the one user.

So ensure that all users have full permissions to that folder (including create, and delete rights). If some users have different permissions, then the scenarios you describe is quite common.

I would also check if the locking file (ldb) is deleted before you attempt to open the database.

So file permissions can cause this, and also other users on the network may still have the older file open, or even the locking file open – who has files open can be viewed + checked by the admin of where that folder resides.

And given that your problem is A VERY VERY different description of the problem outlined in this thread – I would have started a new thread, since in your case just changing the location of the file fixes your problem. Moving to a different folder location is not going to change or fix a bad network issue, so your issue centers on permissions, or as noted some stray users have the file still open in original location.

Regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada