multiple users' simultaneous access to a MS Access database

  • Thread starter Thread starter zufie
  • Start date Start date
Z

zufie

When my end user clicks on the icon for her MS Access database (the
icon is on her Novell NAL menu) she is successful in opening the
database.

However, when another staff member is using the database she receives
the message that someone is using it and she cannot access it at that
time.

Any suggestions as to what I need to do to resolve this? I guess it
would be a fix to allow multiple users simultaneous access to a MS
Access database?

Thanks in advance, Zuf
 
When my end user clicks on the icon for her MS Access database (the
icon is on her Novell NAL menu) she is successful in opening the
database.

However, when another staff member is using the database she receives
the message that someone is using it and she cannot access it at that
time.

Any suggestions as to what I need to do to resolve this? I guess it
would be a fix to allow multiple users simultaneous access to a MS
Access database?

Thanks in advance, Zuf
Click to expand...

A multiuser database should - I'd say MUST! - be "split" into a backend
containing just the tables and a frontend with the forms, reports, queries and
code: see http://www.granite.ab.com/access/splitapp.htm for a discussion. This
will solve your problem.
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com
 
A multiuser database should - I'd say MUST! - be "split" into a backend
containing just the tables and a frontend with the forms, reports, queries and
code: seehttp://www.granite.ab.com/access/splitapp.htmfor a discussion. This
will solve your problem.
--

             John W. Vinson [MVP]
 Microsoft's replacements for these newsgroups:
 http://social.msdn.microsoft.com/Forums/en-US/accessdev/
 http://social.answers.microsoft.com/Forums/en-US/addbuz/
 and see alsohttp://www.utteraccess.com
Click to expand...

It already is John. Wish that was the fix, believe me. I was also
referred to the following link regarding .ldb file in MS Access and
user rights. That is, what user rights are granted on the folder
containing the .mbd file? Are they read, write, create, and delete
privileges? If not, a .ldb file cannot be created, correct?

http://support.microsoft.com/kb/208778

What do you think?
 
m:
It already is John.
Click to expand...

There are two parts to properly distributing a multi-user Access
app:

1. split front end and back end.

2. give an individual copy of the front end to each user.

You seem to be saying you've done #1, but you don't indicate that
you've done #2. If you were doing #2, the rest of your reply would
only apply to the back end, but it seems to me like you're still
talking about the front end, which would mean you've not done #2.
Wish that was the fix, believe me. I was also
referred to the following link regarding .ldb file in MS Access
and user rights. That is, what user rights are granted on the
folder containing the .mbd file? Are they read, write, create, and
delete privileges? If not, a .ldb file cannot be created, correct?

http://support.microsoft.com/kb/208778

What do you think?
Click to expand...

The article is actually wrong that DELETE permission is required.
Read/Write/Create/Modify are required, but DELETE is optional.

But this can't possibly have anything to do with the front end, only
with the back end, unless, of course, you've made the mistake of not
doing step #2 above.

It's not possible to say from what you've posted.
 
There are two parts to properly distributing a multi-user Access
app:

1. split front end and back end.

2. give an individual copy of the front end to each user.

You seem to be saying you've done #1, but you don't indicate that
you've done #2. If you were doing #2, the rest of your reply would
only apply to the back end, but it seems to me like you're still
talking about the front end, which would mean you've not done #2.


The article is actually wrong that DELETE permission is required.
Read/Write/Create/Modify are required, but DELETE is optional.

But this can't possibly have anything to do with the front end, only
with the back end, unless, of course, you've made the mistake of not
doing step #2 above.

It's not possible to say from what you've posted.
Click to expand...


This is what my HelpDesk person told me:

"I believe the Users rights to the folder are requested by the DB/
folder owner/administrator, and is established when their access is
granted and they are entered as a trustee.

I looked at the application icon and it points to the DB file:
WHLP.mdb, located at:

\\10.8.16.21\DATA\APPS\Production\OWH\WHL\DOC\SourceCode\Executable\

There are no Users specifically listed as trustees for this folder,
but Miriam does have full rights through inherited rights. The same
for the DB file, itself.

Since that should remove folder/file rights to the DB as the issue, I
would wonder if the DB might contain some calls to other files that
may be outside this folder, where the rights wouldn’t extend, like
does the PROD DB call on files located within TEST, or something along
those lines.

Beyond that, I wouldn’t be able to speculate without more details.
The DB creator and/or administrator would need to go over the code to
determine if there are internal issues at play, here."

Previous to this, my HelpDesk person told me: "I added the app to my
profile and am able to access the proper DB normally."
 
Back
Top