Re: Different MDW files
- From: "Albert D. Kallal" <PleaseNOOOsPAMmkallal@xxxxxxx>
- Date: Thu, 21 Jun 2007 19:43:46 -0600
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...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@xxxxxxx
.
- Follow-Ups:
- Re: Different MDW files
- From: Don Barton
- Re: Different MDW files
- References:
- Different MDW files
- From: Don Barton
- Different MDW files
- Prev by Date: Re: Disable Design View?
- Next by Date: Disable Security - help!
- Previous by thread: Different MDW files
- Next by thread: Re: Different MDW files
- Index(es):
Relevant Pages
|
