Shared Drive Woes on the Backend

ALewis06

Registered User.
Local time
Today, 19:27
Joined
Jun 21, 2012
Messages
124
I have split my database and the BE is sitting in a folder one level down on a shared network drive. It's slow but works.....most of the time. The problem is that everyday when I boot up my pc, initially there's a red X over my shared drive location. Once I double click it, it "activates" it and opens fine. The problem is if I don't do that each and every time prior to opening my Access db, then I get an error message saying that it's an invalid path.

Any ideas how I can solve this? I have to work out all the kinks before rolling out this db to multiple end users.
 
In fairness this is not a problem with your database but with your PC and the network. If you fix the fault on your PC other PCs may have the same problem when you distribute it so this will not help.

If a user receives it and it will not load because of this you could point out that neither would a word document, excel spreadsheet or anything else from the network, it is a windows problem quite common to basic shared networks.

I honestly do not think you can solve it from within access as a procedure to fix a supposed broken network link would fall over really badly if there actually was not a network link at all.

I have had the same problem in my office and advise people to fix their network link, in desperation you could always get your database to put up a message box explaining this if the BE doesn't load.
 
it may be some sort of network set up that drops a connection if the network is not used in a given period.

one way of avoiding this may be to maintain a persistent connection to the data tables, if you are not already doing so.
 
In my experience this is an issue with basic shared drives with no server. When computers are logged on occasionally for some reason they do not configure the network drive. It is as if it is there but it hasn't noticed it.

In Explorer the network drive has a cross against it but if you click on it, the computer then notices that it is there, I really cannot imagine that Access could do anything with this.
 
Where I used to work, we had the problem that you mention. The solution that worked for were I used to work was to use Microsoft SQL Server as the back-end. Problem solved. Note the comment below.
In fairness this is not a problem with your database but with your PC and the network.
Other potential approaches to solving your back-end issue include: Microsoft SQL Express and Mysql. There are other (fee) open-source databases that can also be used.

Note: The approach that I mentioned above was only done once, meaning that I do not have an extensive history of solving this type of back-end issue.
 
Last edited:
I was able to solve this issue on my database by linking the tables to the "true name" of the path. Instead of "S:/Sales/..." I coded in the name of the server, "//[ServerName]:/Sales/...". Maybe that will work for you too?
 
I was able to solve this issue on my database by linking the tables to the "true name" of the path. Instead of "S:/Sales/..." I coded in the name of the server, "//[ServerName]:/Sales/...". Maybe that will work for you too?

This is the solution I used to solve my problem. Using a UNC path vice the virtual path has eliminated it completely.
 
in an ideal world, I would always use UNC path, there is no guarantee that a mapped drive has the same mapping on each device. Not proven but I believe there is a performance benefit as well - providing the path is quite short.
 
...Not proven but I believe there is a performance benefit as well - providing the path is quite short.

I would say that I have noticed a performance increase, but it could a case of me seeing what I want to see rather that real metrics.
 
I get a similar error message that my computer can't restored linked network drives every time I boot it, once or twice a week. But the drive is always there when I need it.

I'd consider writing a little utility that would run on startup with a slight delay that would do a DIR [x]:\ to 'wake up' the connection. But I'd try the UNC trick first.
 
I have code in either the sample databases or code repository that tests if the backend location is connected. You could try that as a fail safe, not a fix. All it does it try and write a text file to the path of the backend and then delete it. If it fails, the we can assume the backend path is not connected or the user does not have write permission.
 
it may be some sort of network set up that drops a connection if the network is not used in a given period.

one way of avoiding this may be to maintain a persistent connection to the data tables, if you are not already doing so.

You can turn that off from the Device Manager, finding the LAN card and clicking the Power Settings tab.

SHADOW
 
Shadow's method works when you have admin rights over your own machine, which we don't always have at my site.

What I did for other reasons, but it applies to this problem, is that we have a main dispatcher / switchboard style of form. Every so often, it queries the "Coming Events" table to see if we have scheduled down-time for the database BE files. The OnTimer event of the main form thus pings the BE file regularly. It is then just a matter of tuning the frequency of that ping to maintain BE activity even if the user is idle.

It is also an excuse for us to drop the user's session if idle too long, though we do it in a way that preserves everything that we can by forcing the open forms and reports to "gracefully" close first.

This might sound difficult to implement, but what we did was set up one of the General Modules to contain the global shutdown code and a Public Date/Time variable that gets checked by the timer code. If the user clicks on any button or does any navigation, some common logging code resets the local copy of that public variable so that we know the last time the user did anything active. Since I use templates that already have this code included it in, each new form or report will have the IdleTimer support built-in.
 

Users who are viewing this thread

Back
Top Bottom