By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,473 Members | 3,504 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,473 IT Pros & Developers. It's quick & easy.

Network Computers Suddenly Can't Access Database?

P: n/a
Hi,

We were going merrily along for 6 years using this database to record
all client checks that came into our office, including information
about what the checks were for.

Suddenly, network computers cannot access the database.

The message is...

"The Microsoft Jet database engine cannot open the file
C:\SomeFolder\SomeSubfolder\Somefile.mdb. It is already opened
exclusively by another user, or you need permission to view its data."

So far as I know, nothing has changed with the permissions, and I made
sure no one else had the file open. The only thing I can think of that
might have affected the file is that I may have compacted the database
on Friday and the problem surfaced the next Tuesday. All the computers
on the network can see each other and share data just fine. The
database contains numerous tables, queries, forms, and reports. It
weighs in at 3.5 MB.

Some of the network computers have a problem opening only this one
file in the subfolder, while other computers can't open any of the
files in the subfolder. In each case, the message is the same. The
network computer on which the files reside can open all the files. All
the network computers can access all the other files (Word, Excel) in
other subfolders within the Folder.

In fact, the subfolders are named, Access, Execl, Word, etc.

1. Failed Home Remedy #1. I rebooted all the computers. No change.
2. Failed Home Remedy #2. I moved all the files into a new subfolder.
This worked for one day. Then, the message appeared again the
following day.
3. Untested Home Remedy #3. I moved all the files into a new subfolder
again, but I also deleted some records, thinking maybe the database is
getting to large with 14,000 records. I reduced the number of records
to less than 12,000.

What could be the problem?
What could be the solution?

Thanks,
MHenry

Nov 12 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
On Wed, 18 Feb 2004 17:18:23 -0800, MHenry wrote:
Hi,

We were going merrily along for 6 years using this database to record
all client checks that came into our office, including information
about what the checks were for.

Suddenly, network computers cannot access the database.

The message is...

"The Microsoft Jet database engine cannot open the file
C:\SomeFolder\SomeSubfolder\Somefile.mdb. It is already opened
exclusively by another user, or you need permission to view its data."

So far as I know, nothing has changed with the permissions, and I made
sure no one else had the file open. The only thing I can think of that
might have affected the file is that I may have compacted the database
on Friday and the problem surfaced the next Tuesday. All the computers
on the network can see each other and share data just fine. The
database contains numerous tables, queries, forms, and reports. It
weighs in at 3.5 MB.

Some of the network computers have a problem opening only this one
file in the subfolder, while other computers can't open any of the
files in the subfolder. In each case, the message is the same. The
network computer on which the files reside can open all the files. All
the network computers can access all the other files (Word, Excel) in
other subfolders within the Folder.

In fact, the subfolders are named, Access, Execl, Word, etc.

1. Failed Home Remedy #1. I rebooted all the computers. No change.
2. Failed Home Remedy #2. I moved all the files into a new subfolder.
This worked for one day. Then, the message appeared again the
following day.
3. Untested Home Remedy #3. I moved all the files into a new subfolder
again, but I also deleted some records, thinking maybe the database is
getting to large with 14,000 records. I reduced the number of records
to less than 12,000.

What could be the problem?
What could be the solution?

Thanks,
MHenry


We ran into something that may be similar to this at my work. Turned out
the workgroup file (in our case system.mdw) was in a folder that some
machines did not have access to. Could your workgroup file have been moved,
reset, or otherwise recently?
--
Mike Storr
www.veraccess.com
Nov 12 '05 #2

P: n/a
Hi, Mike,

I don't think the file was moved or reset prior to the problem.
But I am not sure what you mean by reset?

MHenry

On Wed, 18 Feb 2004 22:24:55 -0500, Mike Storr <st******@sympatico.ca>
wrote:
On Wed, 18 Feb 2004 17:18:23 -0800, MHenry wrote:
Hi,

We were going merrily along for 6 years using this database to record
all client checks that came into our office, including information
about what the checks were for.

Suddenly, network computers cannot access the database.

The message is...

"The Microsoft Jet database engine cannot open the file
C:\SomeFolder\SomeSubfolder\Somefile.mdb. It is already opened
exclusively by another user, or you need permission to view its data."

So far as I know, nothing has changed with the permissions, and I made
sure no one else had the file open. The only thing I can think of that
might have affected the file is that I may have compacted the database
on Friday and the problem surfaced the next Tuesday. All the computers
on the network can see each other and share data just fine. The
database contains numerous tables, queries, forms, and reports. It
weighs in at 3.5 MB.

Some of the network computers have a problem opening only this one
file in the subfolder, while other computers can't open any of the
files in the subfolder. In each case, the message is the same. The
network computer on which the files reside can open all the files. All
the network computers can access all the other files (Word, Excel) in
other subfolders within the Folder.

In fact, the subfolders are named, Access, Execl, Word, etc.

1. Failed Home Remedy #1. I rebooted all the computers. No change.
2. Failed Home Remedy #2. I moved all the files into a new subfolder.
This worked for one day. Then, the message appeared again the
following day.
3. Untested Home Remedy #3. I moved all the files into a new subfolder
again, but I also deleted some records, thinking maybe the database is
getting to large with 14,000 records. I reduced the number of records
to less than 12,000.

What could be the problem?
What could be the solution?

Thanks,
MHenry


We ran into something that may be similar to this at my work. Turned out
the workgroup file (in our case system.mdw) was in a folder that some
machines did not have access to. Could your workgroup file have been moved,
reset, or otherwise recently?


Nov 12 '05 #3

P: n/a
MHenry,
1. Check permissions for that folder on your server and ensure that no one
has changed them and shut off access to the file. Dope slap the idiot that
did, if this is the case.
2. Check the preferences of each client instance of Access to ensure that
no one is opening the thing exclusively. Dope slap the idiot that did, if
this is the case.
2. Check the hard drive on which the file is stored and ensure it has at
least 20% of it's capacity available. If it's full, go get a bigger hard
drive so access has room to write temporary files as it does its job.
3. Check all the associated networking stuff and make sure it is still
stable. Access, (particularly Access 97) can be finicky about network
connectivity.
4. Check the properties of the file and ensure no one has set it to
read-only. Dope slap the idiot that did, if this is the case.
5. Run a compact & repair on a *copy* of the file. In fact, in spite of
the iffiness of the current database, burn a CD with it as is, just in case,
and then do the compact & repair on the copy(s).
6. Assuming all the above is fine, create a new Access database file and
import the data from the file you burned onto a CD into the new file.
Carefully examine the imported data to ensure the data is still valid & if
not, figure out what to do with the garbledged (I know that garbledged isn't
a word, leave me be) data.

The error you are experiencing can occur when either the server went down
with a lock on the file while a user had it open and that lock didn't get
released when the server was restarted, Access crashed mid-transaction and
left a lock in the .ldb file it creates to track locks on tables/records,
etc., or a co-worker had a brain fart and opened the thing exclusively thus
kicking everyone else out of the pool. If it was open exclusively and
either the server went down or Access went down then the files last known
state was open exclusive and you have to force Access or the OS to let go of
the file--thus the recommendation to try a Compact & Repair.

"MHenry" <MH****@NoSpam.net> wrote in message
news:kk********************************@4ax.com...
Hi,

We were going merrily along for 6 years using this database to record
all client checks that came into our office, including information
about what the checks were for.

Suddenly, network computers cannot access the database.

The message is...

"The Microsoft Jet database engine cannot open the file
C:\SomeFolder\SomeSubfolder\Somefile.mdb. It is already opened
exclusively by another user, or you need permission to view its data."

So far as I know, nothing has changed with the permissions, and I made
sure no one else had the file open. The only thing I can think of that
might have affected the file is that I may have compacted the database
on Friday and the problem surfaced the next Tuesday. All the computers
on the network can see each other and share data just fine. The
database contains numerous tables, queries, forms, and reports. It
weighs in at 3.5 MB.

Some of the network computers have a problem opening only this one
file in the subfolder, while other computers can't open any of the
files in the subfolder. In each case, the message is the same. The
network computer on which the files reside can open all the files. All
the network computers can access all the other files (Word, Excel) in
other subfolders within the Folder.

In fact, the subfolders are named, Access, Execl, Word, etc.

1. Failed Home Remedy #1. I rebooted all the computers. No change.
2. Failed Home Remedy #2. I moved all the files into a new subfolder.
This worked for one day. Then, the message appeared again the
following day.
3. Untested Home Remedy #3. I moved all the files into a new subfolder
again, but I also deleted some records, thinking maybe the database is
getting to large with 14,000 records. I reduced the number of records
to less than 12,000.

What could be the problem?
What could be the solution?

Thanks,
MHenry

Nov 12 '05 #4

P: n/a
Alan,

This is really a great answer.
I will try all these things tomorrow.
And will report the results to the group.

Thanks,
MHenry

On Thu, 19 Feb 2004 01:09:46 -0500, "Alan Webb" <kn*****@hotmail.com>
wrote:
MHenry,
1. Check permissions for that folder on your server and ensure that no one
has changed them and shut off access to the file. Dope slap the idiot that
did, if this is the case.
2. Check the preferences of each client instance of Access to ensure that
no one is opening the thing exclusively. Dope slap the idiot that did, if
this is the case.
2. Check the hard drive on which the file is stored and ensure it has at
least 20% of it's capacity available. If it's full, go get a bigger hard
drive so access has room to write temporary files as it does its job.
3. Check all the associated networking stuff and make sure it is still
stable. Access, (particularly Access 97) can be finicky about network
connectivity.
4. Check the properties of the file and ensure no one has set it to
read-only. Dope slap the idiot that did, if this is the case.
5. Run a compact & repair on a *copy* of the file. In fact, in spite of
the iffiness of the current database, burn a CD with it as is, just in case,
and then do the compact & repair on the copy(s).
6. Assuming all the above is fine, create a new Access database file and
import the data from the file you burned onto a CD into the new file.
Carefully examine the imported data to ensure the data is still valid & if
not, figure out what to do with the garbledged (I know that garbledged isn't
a word, leave me be) data.

The error you are experiencing can occur when either the server went down
with a lock on the file while a user had it open and that lock didn't get
released when the server was restarted, Access crashed mid-transaction and
left a lock in the .ldb file it creates to track locks on tables/records,
etc., or a co-worker had a brain fart and opened the thing exclusively thus
kicking everyone else out of the pool. If it was open exclusively and
either the server went down or Access went down then the files last known
state was open exclusive and you have to force Access or the OS to let go of
the file--thus the recommendation to try a Compact & Repair.

"MHenry" <MH****@NoSpam.net> wrote in message
news:kk********************************@4ax.com.. .
Hi,

We were going merrily along for 6 years using this database to record
all client checks that came into our office, including information
about what the checks were for.

Suddenly, network computers cannot access the database.

The message is...

"The Microsoft Jet database engine cannot open the file
C:\SomeFolder\SomeSubfolder\Somefile.mdb. It is already opened
exclusively by another user, or you need permission to view its data."

So far as I know, nothing has changed with the permissions, and I made
sure no one else had the file open. The only thing I can think of that
might have affected the file is that I may have compacted the database
on Friday and the problem surfaced the next Tuesday. All the computers
on the network can see each other and share data just fine. The
database contains numerous tables, queries, forms, and reports. It
weighs in at 3.5 MB.

Some of the network computers have a problem opening only this one
file in the subfolder, while other computers can't open any of the
files in the subfolder. In each case, the message is the same. The
network computer on which the files reside can open all the files. All
the network computers can access all the other files (Word, Excel) in
other subfolders within the Folder.

In fact, the subfolders are named, Access, Execl, Word, etc.

1. Failed Home Remedy #1. I rebooted all the computers. No change.
2. Failed Home Remedy #2. I moved all the files into a new subfolder.
This worked for one day. Then, the message appeared again the
following day.
3. Untested Home Remedy #3. I moved all the files into a new subfolder
again, but I also deleted some records, thinking maybe the database is
getting to large with 14,000 records. I reduced the number of records
to less than 12,000.

What could be the problem?
What could be the solution?

Thanks,
MHenry


Nov 12 '05 #5

P: n/a
It is possible to specify a workgroup file in the command line of a DB
shortcut (and maybe elsewhere) to one other than System.mdw. If it's more
than one machine this is not likely the problem, but I thought I'd throw in
the idea.
"MHenry" <MH****@NoSpam.comcast.net> wrote in message
news:pq********************************@4ax.com...
Hi, Mike,

I don't think the file was moved or reset prior to the problem.
But I am not sure what you mean by reset?

MHenry


Nov 12 '05 #6

P: n/a
MHenry <MH****@NoSpam.comcast.net> wrote in
news:1n********************************@4ax.com:
This is really a great answer.
I will try all these things tomorrow.
And will report the results to the group.


I get the distinct impression from your message that you have a
single MDB file with tables and forms and so forth that is being
opened by all your users.

This is a recipe for disaster.

The fact that you've managed to run this way for 6 years problem
free is borderline miraculous.

Split the application into a data MDB with tables only in the
existing location and a program MDB that is on each users'
workstation.

You will have far fewer problems of all kinds with this setup and be
far, far safer. For one, it won't matter then if someone is set to
exclusive access, as it will only apply to the front end (that
setting can't be imposed on a back end that is opened via linked
tables).

Indeed, it's better for the workstations to be set to EXCLUSIVE in
this scenario, anyway, because performance will be better in opening
the MDB file on the workstation that is not being shared with anyone
else.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #7

P: n/a
Hi, David,

Thanks for the advice.
I have never split a database into a data mdb and a program mdb and
linked to the data, but I imagine I can figure out how to do it. Is it
no more complicated than putting all the queries, forms, and reports
in one database file (program database), then the tables in another
(data database), and linking to the table in the data database from
the program database (with some easy clicks on the file menu)?

MHenry

On Thu, 19 Feb 2004 19:32:47 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
MHenry <MH****@NoSpam.comcast.net> wrote in
news:1n********************************@4ax.com :
This is really a great answer.
I will try all these things tomorrow.
And will report the results to the group.


I get the distinct impression from your message that you have a
single MDB file with tables and forms and so forth that is being
opened by all your users.

This is a recipe for disaster.

The fact that you've managed to run this way for 6 years problem
free is borderline miraculous.

Split the application into a data MDB with tables only in the
existing location and a program MDB that is on each users'
workstation.

You will have far fewer problems of all kinds with this setup and be
far, far safer. For one, it won't matter then if someone is set to
exclusive access, as it will only apply to the front end (that
setting can't be imposed on a back end that is opened via linked
tables).

Indeed, it's better for the workstations to be set to EXCLUSIVE in
this scenario, anyway, because performance will be better in opening
the MDB file on the workstation that is not being shared with anyone
else.

Nov 12 '05 #8

P: n/a
Alan,

I went through most of the steps you suggested (did not burn CD, but
have copies of database on other computers), but nothing seemed to
work. However, the plot thickened today.

When the main user went to close the database file today, a message
said "you are trying to create or rename a file that already exists."
I happened to see that message just before she unthinkingly clicked
out of it (I dope slapped her). I managed to repeat the error message
a couple of times without being able to figure out why it was
happening. After the second repetition, we got back to the error I
mentioned before... "can't access database... etc." The same process
happened on another database file, too. I decided on the spot to
uninstall and reinstall office, and suspect that some setting in
Access on that particular computer was messed up, or the program got
corrupted somehow. So far, the reinstall has cured the new error
message, but I will have to give it a couple of days, or more, to see
if this is the fix or not.

Thanks to everyone who helped me understand what was happening and how
to approach a fix.

I may still need you.

MHenry
On Thu, 19 Feb 2004 01:09:46 -0500, "Alan Webb" <kn*****@hotmail.com>
wrote:
MHenry,
1. Check permissions for that folder on your server and ensure that no one
has changed them and shut off access to the file. Dope slap the idiot that
did, if this is the case.
2. Check the preferences of each client instance of Access to ensure that
no one is opening the thing exclusively. Dope slap the idiot that did, if
this is the case.
2. Check the hard drive on which the file is stored and ensure it has at
least 20% of it's capacity available. If it's full, go get a bigger hard
drive so access has room to write temporary files as it does its job.
3. Check all the associated networking stuff and make sure it is still
stable. Access, (particularly Access 97) can be finicky about network
connectivity.
4. Check the properties of the file and ensure no one has set it to
read-only. Dope slap the idiot that did, if this is the case.
5. Run a compact & repair on a *copy* of the file. In fact, in spite of
the iffiness of the current database, burn a CD with it as is, just in case,
and then do the compact & repair on the copy(s).
6. Assuming all the above is fine, create a new Access database file and
import the data from the file you burned onto a CD into the new file.
Carefully examine the imported data to ensure the data is still valid & if
not, figure out what to do with the garbledged (I know that garbledged isn't
a word, leave me be) data.

The error you are experiencing can occur when either the server went down
with a lock on the file while a user had it open and that lock didn't get
released when the server was restarted, Access crashed mid-transaction and
left a lock in the .ldb file it creates to track locks on tables/records,
etc., or a co-worker had a brain fart and opened the thing exclusively thus
kicking everyone else out of the pool. If it was open exclusively and
either the server went down or Access went down then the files last known
state was open exclusive and you have to force Access or the OS to let go of
the file--thus the recommendation to try a Compact & Repair.

"MHenry" <MH****@NoSpam.net> wrote in message
news:kk********************************@4ax.com.. .
Hi,

We were going merrily along for 6 years using this database to record
all client checks that came into our office, including information
about what the checks were for.

Suddenly, network computers cannot access the database.

The message is...

"The Microsoft Jet database engine cannot open the file
C:\SomeFolder\SomeSubfolder\Somefile.mdb. It is already opened
exclusively by another user, or you need permission to view its data."

So far as I know, nothing has changed with the permissions, and I made
sure no one else had the file open. The only thing I can think of that
might have affected the file is that I may have compacted the database
on Friday and the problem surfaced the next Tuesday. All the computers
on the network can see each other and share data just fine. The
database contains numerous tables, queries, forms, and reports. It
weighs in at 3.5 MB.

Some of the network computers have a problem opening only this one
file in the subfolder, while other computers can't open any of the
files in the subfolder. In each case, the message is the same. The
network computer on which the files reside can open all the files. All
the network computers can access all the other files (Word, Excel) in
other subfolders within the Folder.

In fact, the subfolders are named, Access, Execl, Word, etc.

1. Failed Home Remedy #1. I rebooted all the computers. No change.
2. Failed Home Remedy #2. I moved all the files into a new subfolder.
This worked for one day. Then, the message appeared again the
following day.
3. Untested Home Remedy #3. I moved all the files into a new subfolder
again, but I also deleted some records, thinking maybe the database is
getting to large with 14,000 records. I reduced the number of records
to less than 12,000.

What could be the problem?
What could be the solution?

Thanks,
MHenry

Nov 12 '05 #9

P: n/a
MHenry <MH****@NoSpam.net> wrote in
news:8q********************************@4ax.com:
I have never split a database into a data mdb and a program mdb
and linked to the data, but I imagine I can figure out how to do
it. Is it no more complicated than putting all the queries, forms,
and reports in one database file (program database), then the
tables in another (data database), and linking to the table in the
data database from the program database (with some easy clicks on
the file menu)?


Yes, and there's a wizard to do it for you.

For what it's worth, I've never created anything but a split
multi-user application, from the very first one I ever did for a
client back in 1996. I just read the Access help file and that's
what it said to do, split the app and put the front end on
workstations.

I've never understood how so many people could end up doing it any
other way, as it is what all Access documentation that I've ever
seen recommends for multi-user applications.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #10

P: n/a
David,
This is just to help you understand how one person, at least, can miss
the obvious, and do it wrong. I learned how to use access by trial and
error (a lot of both). The extent of my knowledge of Access is
superficial at best. My first use was in the single user environment,
but I never saw any reference to mulit-user databases in the help
files as I meddled my way through the morass. As soon as I knew
enough to do the things I needed to do with Access, I relied less and
less on the help files. In fact, I never knew that there would be
special considerations for multiuser databases. I simply assumed that
other users just needed to find the database on my hard drive and have
at it. As I indicated, it has worked for six years. So, I will count
myself lucky and fix it now that I am aware of it.
Thanks,
MHenry
On Fri, 20 Feb 2004 01:34:50 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
MHenry <MH****@NoSpam.net> wrote in
news:8q********************************@4ax.com :
I have never split a database into a data mdb and a program mdb
and linked to the data, but I imagine I can figure out how to do
it. Is it no more complicated than putting all the queries, forms,
and reports in one database file (program database), then the
tables in another (data database), and linking to the table in the
data database from the program database (with some easy clicks on
the file menu)?


Yes, and there's a wizard to do it for you.

For what it's worth, I've never created anything but a split
multi-user application, from the very first one I ever did for a
client back in 1996. I just read the Access help file and that's
what it said to do, split the app and put the front end on
workstations.

I've never understood how so many people could end up doing it any
other way, as it is what all Access documentation that I've ever
seen recommends for multi-user applications.


Nov 12 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.