Add New User to Secured DB

[dee]

Hi,

I have had great advice here and my db is humming along beautifully. I have
followed Joan's steps in securing, have the shortcut to the FE on the various
workstations, etc.

My question now is - when I add a new user or remove an existing user - how
do I proceed?

I have logged on as the administrator, added the user, assigned them to a
group, then closed Access, re-opened and logged on as the new user to set the
password.

This was done in the original database. Do I now need to repeat the process
in the FE and BE and then recreate my MDE file and redistribute?

Thank so much!

 

[Joan Wild]

No, you don't do that.

The usernames/passwords are stored in the mdw file. Presumably you have that on the server and it's shared by everyone. So when you make those changes, you are doing so in this file. The changes are in place for everyone.

If you actually have a separate mdw for development, then you'll need to make the same changes in the production mdw.

 

[dee]

Thanks for your response, Joan. So, I understand now that the users and
groups are stored in the mdw, so when I modify them when my session is using
that mdw, they will be stored there.

From what I gather, though, the permissions are stored in the db. If I wish
to modify or add permissions to a newly created group, do I have to do so in
the original db, then re-split it?

Along the same vein, if I am not using an automatic db updater, and wish to
modify either tables or forms, this is what I do manually:
1) Open the original, secured db and make the changes.
2) Make sure nobody is logged in and import the newly updated tables into
the BE
3) Import the forms, queries, etc. that I have updated into the FE
4) Either log on as users (I only have 3) and copy the new FE to replace
their existing local FE OR send them a copy via e-mail and have them save it
and replace the original.

Does this sense?
Thanks again.

--
Thanks!

Dee

No, you don't do that.

The usernames/passwords are stored in the mdw file. Presumably you have that on the server and it's shared by everyone. So when you make those changes, you are doing so in this file. The changes are in place for everyone.

If you actually have a separate mdw for development, then you'll need to make the same changes in the production mdw.

 

[Joan Wild]

From what I gather, though, the permissions are stored in the db.
Yes

If I wish
to modify or add permissions to a newly created group, do I have to do so in
the original db, then re-split it?

No, you should be able to do this in the split db.

Along the same vein, if I am not using an automatic db updater, and wish to
modify either tables or forms, this is what I do manually:
1) Open the original, secured db and make the changes.
2) Make sure nobody is logged in and import the newly updated tables into
the BE

Not a good idea. When you import, the permissions don't travel with the object. You need to open the production BE (when no one is using it) and make the changes there. You can make changes and test in your copy of the BE, and once you're ready then make them in the production BE.

3) Import the forms, queries, etc. that I have updated into the FE

Again, importing loses all the permissions. You need to make these changes in your copy of the FE, and then copy it out to the users, over-writing their copy.

4) Either log on as users (I only have 3) and copy the new FE to replace
their existing local FE OR send them a copy via e-mail and have them save it
and replace the original.

I don't see why you need to log on as a user to copy a file.

You should just be making changes in your copy of the FE (and also a separate 'test' copy of the BE). Once you are finished testing, you make the necessary changes in the BE, and then copy your changed FE to all the users.

 

[dee]

I think where I'm going wrong is still relying on the secured but unsplit
database.

From what I am understanding (?), I should now just work with the FE and
BEs, making copies that I modify and then replace the BE on the server when
nobody is logged in and replacing the FE on the server, plus on each user's
workstation. The reason I said I would log in as the user is that I don't
have access to their local workstation folders otherwise, so can't navigate
to the file where their local copy is stored to copy over it.

If I am only working with the BE and the FE, this will make my life a lot
easier. I also know I must compact the db regularly, and have been
researching this. From what I gather, Compact on Close isn't recommended and
I only need to compact the BE. Does that sound right? Some opinions are to
compact once every 6 months and others every day. Would one a month be a
good option?

Thanks for all of your valuable help and input, as always, Joan.

 

[dee]

As a follow-up, Joan, aren't the permissions I set for New Tables, New Forms,
etc. respected with I import?

 

[Joan Wild]

From what I am understanding (?), I should now just work with the FE and
BEs, making copies that I modify and then replace the BE on the server when
nobody is logged in and replacing the FE on the server, plus on each user's
workstation.

Well you don't want to copy over the BE, or you'll overwrite any data changes the users have done. You need to make the changes in the BE.

From what I gather, Compact on Close isn't recommended and
I only need to compact the BE. Does that sound right? Some opinions are to
compact once every 6 months and others every day. Would one a month be a
good option?

Once a month should be fine.

 

[Joan Wild]

As a follow-up, Joan, aren't the permissions I set for New Tables, New Forms,
etc. respected with I import?

Yes they are, however it is unusual that you'd want the same permissions for *everything* that you import.

 

[dee]

yes, I see what you're saying. Due to the fact that mine is a rather small
database with pretty clear-cut permissions, it hasn't been an issue, but one
I must look at more closely.

Thanks so much again, Joan. I really appreciate all of your help! Have a
great weekend!