Necessary Permissions

[Guest]

I have a db that is located on a secure server. The db itself is not secured
with usernames and/or passwords. This db will be used in a multi-user
environment. Each user will access this using a shortcut on their desktop.
For most of the users, this has not been a problem. However, a few receive a
message "You do not have the necessary permissions to use this {path name}
object."

After reading several other posts, I understand this is related to the
workgroup assigned. I've tried to search for MDW files on the effected PC
and only found one file. This is the file and path when I check the
workgroup.

This is really puzzling and I'm a bit lost. These particular users are able
to work in other db's that I've designed and stored in the same place. I'm
unsure why this new db would cause such a problem.

Thank you in advance!!

 

[Lynn Trapp]

Do all the users have full permissions to the folder where the database
resides?

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html

 

[Guest]

Yes, all users have full permissions on the folder.

 

[Lynn Trapp]

Does the shortcut you have provided them point to a specific workgroup
information file?

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html

 

[Guest]

The shortcut points the user to the access file on our server.

 

[Lynn Trapp]

Can you post your shortcut Target? It still seems to me that there is some
kind of network permission error. Does this happen to those few users all
the time or only if they are the first person trying to open the database?

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html

 

[Guest]

"I:\temp\Phone Log V5.mdb"

Our network people have looked at this too. They said it could have
something to do with the user's profile on the computer, but wouldn't know
for sure until they wiped out the profile and started completely over. This
will be a lengthy process and we wanted to be sure this is the problem before
we go down that path. Wiping out the user's profile is a "guess" that it
could help with this problem. They aren't certain and are a bit baffled.

The users who are experiencing this problem are able to access the same
drive and similar files without a problem. The only difference in these
files is that this one has not been split yet and has code that collects the
username to be stored in a specified field.

 

[Lynn Trapp]

I'm afraid that I'm baffled. This is the kind of error that should fire when
a user doesn't have the ability to create a new file and, thus, can't create
the lock file (.ldb) that is created when the database is first opened.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html

 

[Guest]

Thank you so much for your help. I've passed this information on to our
network staff to investigate. If you find anyone else who has run into this
problem and found a solution, please let me know. Thanks again, Lynn!

 

[Lynn Trapp]

You're quite welcome. Perhaps Joan Wild or some of the others are monitoring
this thread and will holler if they see something that I didn't.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html

 

[Joan Wild]

An easy way to test if the user(s) have the proper permission on the folder,
is to open the folder in Windows Explorer. Have the user right-click,
choose New...Text Document. Type some junk and save the file. Close it.
Now attempt to delete it.

If they can do all that, then they have the proper permissions on the
folder.

Repeat the test with each user, until you find the one that fails - that
user has the improper permissions.