Problem adding group to user-level security

  • Thread starter Thread starter Craig
  • Start date Start date
C

Craig

Hello,

I have an Access 2003 database split into FE/BE, which is used by a handful
of users on a network. The front end is on each user's local machine and the
back end is on a server.

I have set up user-level security on this database, and the security file,
(Security.mdw) is on the network in the same folder as the back end. The
users all have a shortcut on their desktop which uses the /wrkgrp switch to
make sure they are using the Security.mdw file during their session. The
users are also running the database in runtime mode, as they do not have the
full version of Access on their computers.

When I first set up the ULS, I had two security groups: the default Users
group, which was basically a read-only group, and a more advanced HR group,
which could add/edit/delete records and view certain forms that the Users
group could not. Everything worked splendidly.

Now I need to add a third group, called Trainers, which will have access to
forms and tables that HR and Users do not.

I added the group, and added a login which belonged to that group, and
everything worked ok --- but only on my computer.

If I logged in as a trainer, I could open the correct form (frmTraining),
which had a subform (frmTrainingIncidents), which showed me training records
by employee (tblTrainingIncidents). I was able to add new records to this
table.

However, if I log in as a trainer on someone else's PC, they can open the
form but they cannot add new records to the table. NOTE that in both cases I
am logging on using the trainer's login --- so everything should work the
same, right?

(Note also that I am able to login as a trainer on someone else's machine,
and even open the form --- so it definitely recognizes the newly-created
login.)

One more piece of information that complicates the picture (or maybe
simplifies it?): There is one user who is a member of both the HR and
Training groups. When she logs on (on her computer) with her login, she can
access the form and add data --- perfect. But if she logs on (on her
computer) using a login of someone who is only in the Training group, the
same problem happens as above.

To summarize:

1. The Training group and login appear to work on my PC, but nobody else's.

2. The user who is a member of the Training and HR group can do everything
that her login is supposed to do.

3. If someone is ONLY a member of the HR group, they cannot do what the
above user can do.

So, somehow, the combination of Training and HR has created the magical
combination that works. And also, my PC is magical too, because everything
works fine there.

Any suggestions on where to start on correcting this? I apologize for the
somewhat facetious tone as I am very frustrated!

All help is greatly appreciated.

Thanks,

Craig
 
So you added a group and a user, which is added to the secure.mdw file on the network (which is why the new username/group it is available to everyone).

You assigned permissions to this group. Permissions, though, are stored in the mdb file (not the mdw). So your copy of the frontend has the permissions applied in it. You now need to distribute the updated frontend to all the other users.

--
Joan Wild
Microsoft Access MVP
: Hello,
:
: I have an Access 2003 database split into FE/BE, which is used by a handful
: of users on a network. The front end is on each user's local machine and the
: back end is on a server.
:
: I have set up user-level security on this database, and the security file,
: (Security.mdw) is on the network in the same folder as the back end. The
: users all have a shortcut on their desktop which uses the /wrkgrp switch to
: make sure they are using the Security.mdw file during their session. The
: users are also running the database in runtime mode, as they do not have the
: full version of Access on their computers.
:
: When I first set up the ULS, I had two security groups: the default Users
: group, which was basically a read-only group, and a more advanced HR group,
: which could add/edit/delete records and view certain forms that the Users
: group could not. Everything worked splendidly.
:
: Now I need to add a third group, called Trainers, which will have access to
: forms and tables that HR and Users do not.
:
: I added the group, and added a login which belonged to that group, and
: everything worked ok --- but only on my computer.
:
: If I logged in as a trainer, I could open the correct form (frmTraining),
: which had a subform (frmTrainingIncidents), which showed me training records
: by employee (tblTrainingIncidents). I was able to add new records to this
: table.
:
: However, if I log in as a trainer on someone else's PC, they can open the
: form but they cannot add new records to the table. NOTE that in both cases I
: am logging on using the trainer's login --- so everything should work the
: same, right?
:
: (Note also that I am able to login as a trainer on someone else's machine,
: and even open the form --- so it definitely recognizes the newly-created
: login.)
:
: One more piece of information that complicates the picture (or maybe
: simplifies it?): There is one user who is a member of both the HR and
: Training groups. When she logs on (on her computer) with her login, she can
: access the form and add data --- perfect. But if she logs on (on her
: computer) using a login of someone who is only in the Training group, the
: same problem happens as above.
:
: To summarize:
:
: 1. The Training group and login appear to work on my PC, but nobody else's.
:
: 2. The user who is a member of the Training and HR group can do everything
: that her login is supposed to do.
:
: 3. If someone is ONLY a member of the HR group, they cannot do what the
: above user can do.
:
: So, somehow, the combination of Training and HR has created the magical
: combination that works. And also, my PC is magical too, because everything
: works fine there.
:
: Any suggestions on where to start on correcting this? I apologize for the
: somewhat facetious tone as I am very frustrated!
:
: All help is greatly appreciated.
:
: Thanks,
:
: Craig
 
Joan,

Thanks for the help. It all seems so simple now --- I don't know why I
overlooked that part. Everything is working the way it should.

Thanks again!

Craig
 
Glad that was it. Thank you for providing enough details and description.

--
Joan Wild
Microsoft Access MVP
: Joan,
:
: Thanks for the help. It all seems so simple now --- I don't know why I
: overlooked that part. Everything is working the way it should.
:
: Thanks again!
:
: Craig
:
:
: "Joan Wild" wrote:
:
: > So you added a group and a user, which is added to the secure.mdw file on the network (which is why the new username/group it is available to everyone).
: >
: > You assigned permissions to this group. Permissions, though, are stored in the mdb file (not the mdw). So your copy of the frontend has the permissions applied in it. You now need to distribute the updated frontend to all the other users.
: >
: > --
: > Joan Wild
: > Microsoft Access MVP
: > : Hello,
: > :
: > : I have an Access 2003 database split into FE/BE, which is used by a handful
: > : of users on a network. The front end is on each user's local machine and the
: > : back end is on a server.
: > :
: > : I have set up user-level security on this database, and the security file,
: > : (Security.mdw) is on the network in the same folder as the back end. The
: > : users all have a shortcut on their desktop which uses the /wrkgrp switch to
: > : make sure they are using the Security.mdw file during their session. The
: > : users are also running the database in runtime mode, as they do not have the
: > : full version of Access on their computers.
: > :
: > : When I first set up the ULS, I had two security groups: the default Users
: > : group, which was basically a read-only group, and a more advanced HR group,
: > : which could add/edit/delete records and view certain forms that the Users
: > : group could not. Everything worked splendidly.
: > :
: > : Now I need to add a third group, called Trainers, which will have access to
: > : forms and tables that HR and Users do not.
: > :
: > : I added the group, and added a login which belonged to that group, and
: > : everything worked ok --- but only on my computer.
: > :
: > : If I logged in as a trainer, I could open the correct form (frmTraining),
: > : which had a subform (frmTrainingIncidents), which showed me training records
: > : by employee (tblTrainingIncidents). I was able to add new records to this
: > : table.
: > :
: > : However, if I log in as a trainer on someone else's PC, they can open the
: > : form but they cannot add new records to the table. NOTE that in both cases I
: > : am logging on using the trainer's login --- so everything should work the
: > : same, right?
: > :
: > : (Note also that I am able to login as a trainer on someone else's machine,
: > : and even open the form --- so it definitely recognizes the newly-created
: > : login.)
: > :
: > : One more piece of information that complicates the picture (or maybe
: > : simplifies it?): There is one user who is a member of both the HR and
: > : Training groups. When she logs on (on her computer) with her login, she can
: > : access the form and add data --- perfect. But if she logs on (on her
: > : computer) using a login of someone who is only in the Training group, the
: > : same problem happens as above.
: > :
: > : To summarize:
: > :
: > : 1. The Training group and login appear to work on my PC, but nobody else's.
: > :
: > : 2. The user who is a member of the Training and HR group can do everything
: > : that her login is supposed to do.
: > :
: > : 3. If someone is ONLY a member of the HR group, they cannot do what the
: > : above user can do.
: > :
: > : So, somehow, the combination of Training and HR has created the magical
: > : combination that works. And also, my PC is magical too, because everything
: > : works fine there.
: > :
: > : Any suggestions on where to start on correcting this? I apologize for the
: > : somewhat facetious tone as I am very frustrated!
: > :
: > : All help is greatly appreciated.
: > :
: > : Thanks,
: > :
: > : Craig
: >
 
Back
Top