Maintaining security on imported objects...

[Brad Pears]

I am making some massive changes in one of our Access 2000 db applications.
I am touching almost every form/query/table/report in the project.

I do not want to have to redo the security on each object. Usually if I am
making only a couple of changes, I make the changes in our
development/testing area and then will go to the live project and "import"
the object. When you do this, it will import the object and add a "1" after
the pobkect name. You then delete the original and rename the new one.,..

Problem is, when you do this, you have to reset the individual and/or group
permissions on the object.

Since I am changing almost every object in this project, I do not want to
have to go through this process with each object. Is there a way I can
import all of my changed objects -- or even better still, copy the entire
front end app over from the development environment and keep the existing
security settings in the associated mdw file??

Thanks,

Brad

 

[Joan Wild]

Problem is, when you do this, you have to reset the individual and/or
group permissions on the object.

That's true - you will lose the security settings on imported objects. You
could script out the permissons and then reapply them after import (there's
a utility at www.daiglenet.com/MSAccess.htm you could modify to do this,
however....

Since I am changing almost every object in this project, I do not
want to have to go through this process with each object. Is there a
way I can import all of my changed objects -- or even better still,
copy the entire front end app over from the development environment
and keep the existing security settings in the associated mdw file??

That is usually the way it's done. Your database should be split, with just
the backend on the server. You then just overwrite the frontend file when
you have an update. By the way, the permissions are not stored in the mdw,
they are stored in the mdb file.

 

[Brad Pears]

Interesting, I always thought that the associated .mdw file contained all
the security settings. What's in the mdw file then if all the security stuff
is in the mdb???

OK, so if I copy over the front end instead (all our users share the front
end - as many of them are on terminal services sessions...) as long as the
security settings are the same on the development side, there shouldn't be a
problem correct?

Thanks,

Brad

 

[Joan Wild]

Interesting, I always thought that the associated .mdw file contained
all the security settings. What's in the mdw file then if all the
security stuff is in the mdb???

I said the permissions (not all the security stuff) is in the mdb. The mdw
contains usernames/PIDs, passwords, group names, user memberships. The mdw
is used to authenticate a user and their group membership. The permission
for said users/groups are attached to the objects in the mdb. This allows
you to use one workgroup file to secure many databases.

OK, so if I copy over the front end instead (all our users share the
front end - as many of them are on terminal services sessions...) as
long as the security settings are the same on the development side,
there shouldn't be a problem correct?

True, however your users should not be sharing the frontend, even in a TS
session. Each user should have their own copy of the frontend. You can
automate updating the frontends. Have a look at Tony Toews' frontend
updater.
http://www.granite.ab.ca/access/autofe.htm

 

[Brad Pears]

Would implementing individual fiont ends improve speed over the sharing of a
common front end? Just what are the issues with sharing front ends? We have
been doing this for a while without any adverse affects to date..

Thanks,

Brad

 

[Joan Wild]

Would implementing individual fiont ends improve speed over the
sharing of a common front end? Just what are the issues with sharing
front ends? We have been doing this for a while without any adverse
affects to date..

One of the main reasons is that you run the risk of corrupting the frontend.