Question Cannot open access database on network

Steve25

Registered User.
Local time
Today, 19:31
Joined
Nov 17, 2006
Messages
13
Hi,

I'm hoping someone on here can help as this is really winding me up now.

We have a small office network. The server is running SBS 2003, two clients are on XP Pro and the third is on Vista Ultimate 64 Bit.

Each client is running Access 2003.

We have an Access database which can be opened by all the clients except the new one (the Vista Ultimate). When we try to open it Access hangs and stops responding. Eventually forcing us to force Access to close. It then leaves the ldb file on the server which stops anyone else opening it.

To make matters even worse we can't delete the ldb file as the server then hangs. We are forced to do a reboot of the server just to delete the ldb file and allow others to open the database.

The database was in 2000 format, but we have tried to change the format to 2002/2003 and it makes no difference.

Any help greatly appreciated.

Steve
 
Have you set up trusted locations in the trust center for all client PCs?
 
Have you set up trusted locations in the trust center for all client PCs?
I think I have, can remind me how to do it?
 
Also, It also sounds like you dont have your database split. If more than one person is going to be using it, you can save yourself a lot of heartache by having a front end/back end.
 
Also, It also sounds like you dont have your database split. If more than one person is going to be using it, you can save yourself a lot of heartache by having a front end/back end.
To be honest the database has been working fine for years, the problems have only started since we brought in the new computer with vista ultimate on it. I'm working from home now and I bring the database home with me. It is working fine on a vista home premium os.
 
Thanks for the help. I'm at home now so will try it out tomorrow or Monday.
 
I think I have, can remind me how to do it?

Sorry, trusted connections is something you do with Access 2007, and I see you said you're doing Access 2003.

When you hang, are you using administrative tools to see exactly who is still connected to the DB?

I don't think this is an Access problem, I think it is a network problem, and you should have your network administrator fix the network.
 
Sorry, trusted connections is something you do with Access 2007, and I see you said you're doing Access 2003.

When you hang, are you using administrative tools to see exactly who is still connected to the DB?

I don't think this is an Access problem, I think it is a network problem, and you should have your network administrator fix the network.
I have a feeling it is more network than Access, but as we are a small business we can't get anyone to come and have a look. Unbelievable really when you consider a recession is on.
 
To be honest the database has been working fine for years, the problems have only started since we brought in the new computer with vista ultimate on it. I'm working from home now and I bring the database home with me. It is working fine on a vista home premium os.

Steve, I would pay attention to what Scooterbug has suggested.

With different O/S's you're only asking for catastrophe with a shared db unless you split it to be FE/BE.

Give each user their own copy of the FE. Databases corrupt in no time flat when they have to manage concurrent differing O/S connections. You obviate this with FE/BE deployment.

btw - network admins should have file unlocking tools. They shouldn't need to reboot the entire server. Once they've unlocked the .ldb you can delete it.

HTH,
John
 
To be honest the database has been working fine for years, the problems have only started since we brought in the new computer with vista ultimate on it. I'm working from home now and I bring the database home with me. It is working fine on a vista home premium os.
Actually, this is a little like saying "I've been playing Russian Roulette for years and haven't killed myself yet." All it takes is one bullet. Not splitting a database for use by multiple users on a network is like playing Russian Roulette. It isn't a matter of IF you will suffer, but WHEN. The database NEEDS to be split AND users should have a copy of the frontend on their machine. See here for more about splitting and the whys.
 
Actually, this is a little like saying "I've been playing Russian Roulette for years and haven't killed myself yet." All it takes is one bullet. Not splitting a database for use by multiple users on a network is like playing Russian Roulette. It isn't a matter of IF you will suffer, but WHEN. The database NEEDS to be split AND users should have a copy of the frontend on their machine. See here for more about splitting and the whys.
Unfortunately it cannot be split.

I have to take it home every night to work on it. It then has to be copied back to the server in the morning.
 
I have to take it home every night to work on it. It then has to be copied back to the server in the morning.
What are you working on? Tables? The design of the table structure should be "finished" if it is in production for several years.

The frontend is simple - you work on it and have an autoupdater that replaces the users' frontends when you've made changes. I've seen a tool that Tony Toews has as well as Bob Larson which can make it so that changes to your frontends are really simple to implement and the users need not be involved.

Again, if you want to continue with corruption issues and all, by all means do not split it and run as is. I am telling you what MUST be done (not SHOULD) in order to avoid corruption and the issues you have described. Making excuses will be fine but in the end, if you keep losing data and having problems, isn't it better to find a DIFFERENT way than doing it the status quo way? I think insanity was defined as trying to do the same failed task over and over again and expecting different results. (true, isn't it?)
 
Unfortunately it cannot be split.

I have to take it home every night to work on it. It then has to be copied back to the server in the morning.
Apologies if this sounded harsh/nasty/not appreciated. I was talking out of my backside - this has been a problem going on over the last week or so and so it has been getting to me.

I've just had a look at this splitting thingy and I can see how it might work with our set up. I've done a split on a back up and so I'll test it over the weekend on our server.

Thank you very much for the help, even if it originally sounded as though I didn't appreciate it.

Steve
 
No problem. Sometimes things have to change in order to get other things to work properly is the main idea. And with Access, it has some very problematic things that, if you don't want the problems, you have to go about dealing with them in a very distinct way. :)
 
Following on from the above I "think" I can copy both the front and the back ends to the hard drive to take home. That way if I need to make changes to the tables at home I can.

But as I said I'll do some testing over the weekend.

Thanks again.

Steve
 
Good luck with it all and have a good weekend! :)
 
Following on from this.

The splitting of the database has made no difference.
 
Following on from the above I "think" I can copy both the front and the back ends to the hard drive to take home. That way if I need to make changes to the tables at home I can.

But as I said I'll do some testing over the weekend.

Thanks again.

Steve

It sounds like you are on the right track, and I am sure that you will find things work out as you want them to.

Note: You just said that "splitting of the database has made no difference".

I did not notice whether you had deployed your FE on a network drive, or on each User's Workstation. The latter (each User's Workstation) is the right way to go. Of course, it also means that changes to the FE will need to be copied up to the users each time they are made. This Forum has addressed that particular issue many times, and there are a few good Auto-Update procedures that are available to help you out.
 
Last edited:

Users who are viewing this thread

Back
Top Bottom