Different MDW files

[Don Barton]

Access 2003 FE/BE configuration. Multi-user database

I have 2 questions:

1. Why is the Workgroup Information file listed under Workgroup
Administrator is different from the one programmed using the security
wizard?
In my FE, under menu Tools->Security-> Workgroup Administrator, the
Workgroup Information File (WIF) is different than the one I setup
under the User Level Security Wizard. The database has been closed
and reopened and they are still different. Fortunately, the correct
WIF is being used, but the one listed under the Workgroup
Administrator is different.

2. What is the most effective way to update a mdw in client
environment?
Full menus have been disabled in the database. I am using mdw. How
do I update the mdw when the Tools menu isn't listed? I found I can
hold the shift key down after putting in my password, and I will get
full menus back, but this kind of defeats the purpose of not having
full menus. Is this the only way? Do I need to add a form with some
DAO routines for adding/editing/deleting users? I really don't want
my clients using the security wizard or any of the other security menu
itemsif possible, yet they will need to update the users from time to
time. I could do this from my copy of the frontend, but they
shouldn't have to call me everytime they want to add/delete someone.

 

[Albert D. Kallal]

1. Why is the Workgroup Information file listed under Workgroup

Administrator is different from the one programmed using the security
wizard?

I not really sure, but the security wizard, and the use of a workgroup file
are not attached, or ms-access does not KNOW what mdb belongs to what
workgroup file.

When you launch ms-access, you *always* are attached to a workgroup file.
When you secure a particular mdb database, the ONLY special attachment it
has to the workgroup file is IF YOU SET the workgroup file. In other words,
I have many different workgroup files, but the ONLY way ms-access knows to
use to what workgroup file is FOR ME TO SPECIFY what workgroup file.

In any applications that I deploy to a client environment, that really
really
really means that I must provide a shortcut to my database, and that
shortcut
will specify the workgroup file. This solves a million problems, and it also
means that the users other applications will default to the users existing
workgroup file and thus no logon prompt etc. will occur. (by the way, from
what your following questions ask, it seems you are using a shortcut).

In my FE, under menu Tools->Security-> Workgroup Administrator, the
Workgroup Information File (WIF) is different than the one I setup
under the User Level Security Wizard.

Yes, it always seems to show what the default one is. However, you likely
never use that administer EXCEPT TO JOIN a file. It is not really a bug, but
that menu option simply shows the DEFAULT. If you override, then what sense
does it make to use that menu option to join a workgroup? I do think this is
a *sort of* a bug (but it simply shows the DEFAULT workgroup file you *will*
be attached to, not the current one. So, it never did show the current
workgroup...it just shows the default one you will be attached to.

If you need to get/see the current workgroup file, then hit ctrl-g, and in
the debug window type:

? SysCmd(acSysCmdGetWorkgroupFile)

2. What is the most effective way to update a mdw in client
environment?

If you need to update, then you doing this the wrong way. the customer will
over time crate new users and new passwords, and assign permissions to
security groups (note I said groups).

You should NEVER NEVER set security for a form, report, query etc to a
actual INDIVIDUAL!!! The INSTANT you do this, you have now in fact put
security for users in the mdb file. That means if you send an update
to your client, then you loose current settings.



So, You have a choice here:


When you set security/permissions for a form, report etc, ALWAYS set
those
permissions to a SECURITY GROUP not a USER!!!! By doing this, means you
can work on a copy of the front end, and also take home a copy of the
security workgroup file. During the week, I sure that new users are being
added to the system. Further, I sure over time, some users will be given
permissions to use a particular form etc. However, since we ALWAYS assign
users to security groups, then in fact we NEVER assign a user to a form,
but only security groups.


This means that as you add new forms, or reports in your application, you
simply assign that report, or form to a EXISTING security group (say, the
sales group, or perhaps the manager group, or the 'read only' group). This
way, you can re-deploy a new front end to the company on site, but develop
off site. All of the many complex changes and assigning of users to security
groups will thus continue to work, and yet you don't care, or even need
their security workgroup file.


The instant you break the above rule, and start assigning forms to actual
users, then in fact that security is CONTAINED IN THE MDB file!!! So, don't
do
that!!


At the end of the day, most applications I have written can be broken down
in to maybe 3, or 5 major security groups. There is some great screen shots,
and an example of the security groups I used here:


http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFrien...


So, the major trick to making this work is to sit down, and build 3 or 5
security groups. Then as you develop the application, you ALWAYS assign
forms
and reports to those security groups. It is only your clients that will
assign users to those actual security groups, but those settings are
contained in the workgroup file. So, you have 100% complete freedom to
email, or simply update your users front end.


The instant you allow your client to add new security groups, or allow them
to assign users to a particular form, then any update you send to them will
LOOSE those settings.


So, as a developer, make the security groups for the client, and as you
develop, assign forms, reports etc. to those security groups.


I really don't want

my clients using the security wizard or any of the other security menu
itemsif possible, yet they will need to update the users from time to
time. I could do this from my copy of the frontend, but they
shouldn't have to call me everytime they want to add/delete someone.

Like I did, you might want to spend part of a afternoon, and make a few
nice security manager screens that makes this stuff VERY easy for your
clients.

I have not posted my "security" manager, but I can email you a copy if you
wish...

 

[Don Barton]

Albert,
Thanks for your clear and detailed answer to my questions. My
response is below.

If you need to get/see the current workgroup file, then hit ctrl-g, and in
the debug window type:

? SysCmd(acSysCmdGetWorkgroupFile)

This is good to know. Thanks for the tip!

If you override, then what sense
does it make to use that menu option to join a workgroup? I do think this is
a *sort of* a bug (but it simply shows the DEFAULT workgroup file you *will*
be attached to, not the current one. So, it never did show the current
workgroup...it just shows the default one you will be attached to.

The fact that MS lists the default workgroup file in the Workgroup
Admistrators, regardless if it is not the one being used, is in my
opinion, misleading and confusing. You don't know how many times I
went back and changed the thing, only to have it change back to the
default (note: it was a "new" default each time; system1.mdw,
system2.mdw, etc.. even more confusing) I finally settled on using
ONLY the wizard, and now security works as I expected it to.

You should NEVER NEVER set security for a form, report, query etc to a
actual INDIVIDUAL!!! The INSTANT you do this, you have now in fact put
security for users in the mdb file. That means if you send an update
to your client, then you loose current settings.

So, you have 100% complete freedom to
email, or simply update your users front end.

This is what I wanted to hear. I do expect to be able to update FE
via email. But how to keep the mdw sync'd was something I hadn't
figured out. This is a huge fact and answers my concerns. The golden
rule is then: New Access objects are assigned to security groups -
never to individuals!!

http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm

Like I did, you might want to spend part of a afternoon, and make a few
nice security manager screens that makes this stuff VERY easy for your
clients.

I have not posted my "security" manager, but I can email you a copy if you
wish...

I would very much like to see a copy of your security manager.
Assigning security should not be the job of the developer, but the
client. I had thought of writing my own routines, but it sounds like
you've done something very similar already.

Thanks again,
You've been very helpful,

Don