none
Error Accessing file. Network connection may have been lost error messsage

    Question

  • I have an Access 2007 database application with lots of forms, reports, etc.  I am all the sudden at a point where when I am editing Visual Basic code in a form, and do a Debug, Compile, I get this error message. "Error Accessing file.  Network connection may have been lost".  I took a look at "http://msepm.hsquared.be/?p=25" as suggested by Hans H in a post relative to Microsoft Project, but that didn't seem to help here.  Can anyone suggest a cause and/or a solution?
    Monday, April 01, 2013 7:43 PM

Answers

  • I realize you mentioned the FE and BE are on the same local machine however, are they in the same folder what is the link used to the BE? C:\Documents\DatabaseFolder or are you using Windows7 Library folder?

    Try deleting the Tables and relinking from scratch making sure to use a direct path rather than the Library path if using Windows7.


    Chris Ward

    Chris,

    Yes, they are in the same folder.  Perhaps it is because I have a mapped drive to simulate the customers install.  T:\Database\Training is where the be and fe reside.  At any rate, it is fixed now that I imported the objects into a new db.

    Tuesday, April 02, 2013 5:04 PM

All replies

  • First, assuming you're talking about a split application, with the back-end database being an MDB or ACCDB, if you're using a wireless network, stop. Access cannot be used reliably in such a setup on wireless networks.

    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Co-author Access Solutions — Tips, Tricks, and Secrets from Microsoft Access MVPs (ISBN 978-0-470-59168-0)

    Monday, April 01, 2013 9:31 PM
  • Doug,

    You are right, I neglected to mention that it was a split application, however, the front end and back end are both on the same machine which is a local machine, not on a remote network server or computer.  I do understand and your advice is well noted regarding the use of wireless networks and Access. (Even though my customers do it against my advice, without too many issues.)

    I conquered the problem by creating a blank DB and importing the objects from the bad db.  While this solved the problem, I would like to know why the problem created itself!!!  Also what I can do to prevent it, and what the crux of the matter is anyhow.  How come access cannot report what the issue really is instead of reverting to what seems to be a incorrect error message?

    Tuesday, April 02, 2013 1:17 PM
  • Sometimes the messages may seem criptic however, if you take out the part that doesn't apply then what you are left with is a hint to the problem.

    "Error Accessing file.  Network connection may have been lost" - does not exist on network

     = Error Accessing File"

    So what is the error?

    Seems to me the crux of the problem is Access is having trouble connecting to the BE. I would guess the issue is related to the link to the Tables. How do you link to the BE? Have you tried deleting the link to the Tables and Re-establishing the link?


    Chris Ward

    Tuesday, April 02, 2013 2:32 PM
  • I neglected to mention that as well.  First thing I did was to try to access the linked tables to see that the link was there, yes it was.  I then re-linked to be sure.  Same result.
    Tuesday, April 02, 2013 2:43 PM
  • It could be an indication of problems with the network card. Access is like the proverbial miner's canary. If there's a network problem, Access will likely find it!


    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Co-author Access Solutions — Tips, Tricks, and Secrets from Microsoft Access MVPs (ISBN 978-0-470-59168-0)

    Tuesday, April 02, 2013 3:22 PM
  • I realize you mentioned the FE and BE are on the same local machine however, are they in the same folder what is the link used to the BE? C:\Documents\DatabaseFolder or are you using Windows7 Library folder?

    Try deleting the Tables and relinking from scratch making sure to use a direct path rather than the Library path if using Windows7.


    Chris Ward

    Tuesday, April 02, 2013 4:25 PM
  • I realize you mentioned the FE and BE are on the same local machine however, are they in the same folder what is the link used to the BE? C:\Documents\DatabaseFolder or are you using Windows7 Library folder?

    Try deleting the Tables and relinking from scratch making sure to use a direct path rather than the Library path if using Windows7.


    Chris Ward

    Chris,

    Yes, they are in the same folder.  Perhaps it is because I have a mapped drive to simulate the customers install.  T:\Database\Training is where the be and fe reside.  At any rate, it is fixed now that I imported the objects into a new db.

    Tuesday, April 02, 2013 5:04 PM
  • Just remember when you distribute the final product not to use a mapped drive if the db exists on a network. Always use a UNC path to avoid connectiviety issues like slowness and different users having different drive letters or users changing the drive directory.

    Chris Ward

    Wednesday, April 03, 2013 1:24 PM
  • Just my 2 cents, but I wouldn't recommend making "use a UNC path" an absolute.

    I worked for a large international company. We ensured that all users always had certain drives mapped consistently. Everyone would have an I: drive, for instance, that was always mapped to whichever server held group data at their particular location. That meant that I could always the front-end look for its back-end in, say, I:\MyProject\MyBackend.accdb and it would work for the user regardless where they were located. It would have been much more difficult to distribute applications if there needed to be a way to have the application map to \\server1\shared\MyProject\MyBackend.accdb in locations A and B, but \\server2\shared\MyProject\MyBackend.accdb in location C. (Of course, this means that the users in locations A and B would have a different backend than the users in location C, but this is appropriate for group-level applications, as opposed to corporate-level applications).


    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Co-author Access Solutions — Tips, Tricks, and Secrets from Microsoft Access MVPs (ISBN 978-0-470-59168-0)

    Wednesday, April 03, 2013 1:49 PM
  • Good perspective Doug.

    On the other hand just doing a quick performance test here indicates on the one database tested, there is a on average ~7% increase in the performance time running certain queries and functions in Mapped locations vs. UNC locations. Can you verify performance changes or does your testing indicate no change?

    The problem we have with mapped drives here, most people have the ability to change the drive name whether by accident or intent. With the UNC path in the App it is not a problem. We have a lot of hyperlinks to network location in the App, so if someone changed a drive it would shut down a lot of hyperlinks. UNC avoids that.

    Thanks Doug!


    Chris Ward

    Friday, April 05, 2013 1:55 PM
  • Sorry, Chris, I'm now retired, so I can no longer check. However, even if there is a performance hit, what I described was the sanctioned way to deploy Access applications while I was there.

    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Co-author Access Solutions — Tips, Tricks, and Secrets from Microsoft Access MVPs (ISBN 978-0-470-59168-0)

    Friday, April 05, 2013 4:39 PM