Access crashing? "Error Accessing File, Network Connection Lost"

[ashleedawg]

I'm getting error from an Access 2016 database (running Windows 10). The error shows several times on open of the database, then most times I try run anything with VBA, and then several times on close of the database.

Screenshot of the error:

Microsoft Visual Basic For Applications:
Error accessing file. Network connection may have been lost.

The database is a single copy, standalone on my home PC. It had 2 linked tables to another local Access DB. I've removed the links and the error persists. I've tried Compact & Repair several times in different conditions, and I tried copying all of the objects to a new, blank database but the errors continue. I also tried the JETCOMP repair utility but I guess it doesn't work on this version of Access.

The problem seems to be related to two forms that I had made temporarily, then deleted the forms, but the modules remain and won't let me open or delete them. (Form_Form1 & Form_Form2)

Any idea what could be causing this? The 'Network Connections' error confuses me since I'm not on a network and the database is a standalone, that parses XML that is queries as text via HTTP GET calls.

Is there a trustworthy "general DB repair" (free) utility out there that you would recommend? Lots of work went into this baby and I'm like to recover as much as possible!

Thanks!

 

[The_Doc_Man]

This might be time for the "Create empty database and import everything from the old one." Look on this forum for posts on this topic as one way to recover corruption. If C&R won't help then abandon the file itself. It is probably too far gone to do any good.

I've never had to do this myself, but I believe you do the tables first, then relationships, then everything else. You do it from the Database Tools menu (?) to Get External Data and from there you can specify the file from which to pull. It will list what you CAN pull. Obviously, when you get to the modules that are obsoleted, you won't pull them over.

 

[ashleedawg]

I tried re-creating the db, first by programmatically importing the objects, and again with 'Get External Data' as you suggested. I've got a couple different errors popping up (attached).

I recently switched from a paid Office365 subscription to a student version (since my student account from years ago still entitles me to Office365 for free!) and it kind of installed one of top of the other, which is approx when the problem started.

So, I will now completely uninstall & reinstall Office365 and see if that helps.

 

[JHB]

Try the decompile command.
http://www.fmsinc.com/microsoftaccess/performance/decompile.asp

If you can find out the form or forms that cause the problem, the solution is to create a new database and import everything except the form (s).
Then create a new form in the new database and manually copy everything from the form in the old database. I.e. Open form in design view, select all using "Select All" copy it and paste all into the new form.
And the same is done with the VBA code behind the form (s).

 

[ashleedawg]

Sure enough, Office had installed two copies of almost identical packages, next to each other, on the same day.

Microsoft Office 365 ProPlus - en-us  v.16.0.8201.2102  (869 MB)
Microsoft Office 365 - en-us          v.16.0.8201.2102  (869 MB)

I uninstalled one, rebooted, uninstalled the other, rebooted, decompiled my DB (as above) for good measure, and now my "copied-to-new-DB" version is working fine. (The original still gives the same errors.)

My fault I guess for thinking I could safely assume that Microsoft would check for an existing installation!

Thanks...

 

[The_Doc_Man]

Ouch! Mixed installations will whack you every time. The registry was probably VERY confused. And in that situation, a copy-out to a blank database wouldn't help because the problem wasn't the database - it was MSACCESS.EXE (or whatever it is called for Ofc365.)

 

[isladogs]

Glad you fixed it.

As well as decompiling, another useful tool is to clean out errors in the hidden system MSysObjects table.
Errors can occur if the db crashes in the middle of development work and you may not realise the effects until weeks or even months later
Since I started doing that, I've not needed to copy all db objects to a new clean database.
Prior to that I had to create a new clean db every couple of months or so for one or more databases.

Of course, if you do create a clean db, you also by definition get a shiny new MSysObjects table.

Just like editing the registry, editing MSysObjects comes with warnings about the risks.
ALWAYS back up first & check everything you modify

See this post in the repository which has details on how to do this:
https://www.accessprogrammers.co.uk/forums/showthread.php?t=293579

BTW it is possible to have 2 DIFFERENT versions of Access on the same PC e.g. 2010 & 2016 - both must be the same bitness (32 or 64)
Swapping between them can cause reference issues but otherwise it works.
It can of course also be done using a VM which is the recommended option.

 

[gemma-the-husky]

I think it will have been an issue with the crashed processes.

I expect that because of that issue, the back end got placed in an "inconsistent state" and started refusing new connections - hence the bogus "network access interrupted" message.

I see access reporting error slightly differently depending on the version of windows.

If you try to open the backend directly you might see the "inconsistent status" - but you won't be able to fix it while the other sessions are connected. You can also that there is an issue by trying to manually delete the ldb/laccdb file. Windows will genuinely report that the locking file is in use.