MDE security issue

[Marcos Serpas]

I have a centrally located back-end database on a server. All users use an
MDE file that links to a secured.MDW file on the server.

If I make a change in security permissions using an MDE file on a local
computer, the changes only take effect on that particular computer.

If I login on another computer the changes I made do not take effect.

I've managed a way around this situation opening the original MDB file,
changing the security setting, compile the MDB, and distrubuting the new MDE
file with the updated settings.

Is this the norm? Why can't it the new security changes take effect by
using any of the MDE since they are all using the same MDW secured file?

Thanks.

ms

 

[Bruce M. Thompson]

I have a centrally located back-end database on a server. All users use an

MDE file that links to a secured.MDW file on the server.

If I make a change in security permissions using an MDE file on a local
computer, the changes only take effect on that particular computer.

If I login on another computer the changes I made do not take effect.

I've managed a way around this situation opening the original MDB file,
changing the security setting, compile the MDB, and distrubuting the new MDE
file with the updated settings.

Is this the norm? Why can't it the new security changes take effect by
using any of the MDE since they are all using the same MDW secured file?

Only the workgroup/user information is stored in the MDW file. The object
permissions are stored in the MDB/MDE file, hence changes in permissions require
redistributing the file to which those permissions pertain.

 

[Bruce M. Thompson]

redistributing the file to which those permissions pertain.

Should read:

"redistributing the file in which those permissions reside."

 

[Albert D. Kallal]

The reason for this is simple:

When you assign users to security groups, you are not modifying, or saving
any security settings in the mdb file. Thus, you only need to modify, or set
your security settings in the workgroup file, and NOT change security in the
mdb file. This also means that you can distribute new front ends to users
and not even be on-site. In other words, the customer can control their own
security (users and what security groups those users belong to).

The instant you start assigning forms/reports etc to individual users, then
you are now setting security in the mdb file. This means that each
workstation must get a new copy of the front end when security settings are
changed for a user. This becomes very difficult manage, and just changing
some security settings for a user should not requite you to re-distribute
the front end. Worse, if you need to do development on a new front end while
the current system is in use, then your client can NOT change security
settings, since when you deploy a new front end, the existing security
settings will be lost. Of course, if only what security groups a person
belongs to is changed, then no re-distribution of the front end is needed.
(users, and what groups they belong to is stored in the workgroup file, and
not the mdb).

So, during the design and development process you have to come up with a set
of security groups that you will use. With some thought, you can usually
come up with a nice set of groups that covers all bases. Then, when you
create a new form, or report, you assign the security groups that the form
belongs to. You should then NEVER HAVE to change this forms secirty
assignment.

If you take look at following screen shots you can see the set of groups
that I made in the 2nd form. There is about 7 groups, and that easily covers
all the aspects for this application.

http://www.attcanada.net/~kallal.msn/RidesSec/index.html

That application has 160 forms, and thus trying to manage security by
assigning forms to a user would be a nightmare regardless of all the above
points I made. So, yes, you can assign forms security to a individual user,
but I would not recommend that you do so.

Once I assing a form to a secirty group, then I never change it. I only
change what users belong to what groups, and that change is ALWAYS in
the workgroup file.

 

[Marcos Serpas]

Thank you Bruce and Albert for your help in clarify this issue.

ms