 Re: Workgroup file at the database level
raydelex wrote:[color=blue]
> I am new to securing a database with logins. My questions is: I want
> only one database to use a new Workgroup file that I have created, not
> all the Access databases that I bring up under my system login. Can
> this be done?
>
> Thanks[/color]
It is important to understand how Access User-Level security works. The
security "environment" is established when Access itself is launched.
Absolutely no MDB or MDE file is involved at this stage.
Point 1)
Access ALWAYS uses a workgroup file when opened. It either uses the user's
default workgroup or it uses the one specified as a command line argument. This
point gets to your original question. More on this below.
Point 2)
The workgroup file being used when Access opens either has a password applied to
the default user "Admin" or it doesn't. If it does, you are prompted to login.
If it does not then you are not prompted. Again the file or files that you
might want to open haven't entered the picture yet. So if you have made your
default workgroup one that has a password on the Admin user then you are always
prompted to login when you open Access. To avoid this leave your default
workgroup as System.mdw and use a command line argument to specify a different
workgroup only when you need to open a secured file. Most people do this by
creating a shortcut with a Target similar to...
"Path to MSAccess.exe" /wrkgrp "Path to MDW" "Path to MDB"
Point 3)
Once you have Access opened you are now in a "security environment" for that
session. In the context of that session Access now knows who you are and what
groups you belong to in the workgroup file that is being used. If you were not
prompted for a login then you are automatically the user "Admin" who is a member
of the group "Users". You are also "sometimes" a member of the group Admins.
The distinction here is that the group Users is identical in all workgroup
files. This is not true of the group Admins.
You could take 1000 System.MDW files that were created by Microsoft and they
would internally have the same PID for the Admins group. Any user created
workgroup file will always have a different PID. So, when you open a secured
MDB with the default System.MDW you will be a member of the group Admins in that
workgroup, but the file you're opening will not recognize that group as the
*correct* Admins group because the PID is wrong.
Point 4)
Each Access file contains data about what users and what accounts are allowed to
do stuff. The most important being what Users/Groups are allowed to open the
file at all. It doesn't care what workgroup file is being used. It only cares
that the User/Group attempting to do something is one that has permissions to do
so.
Point 5)
Now...we actually attempt to open a particular file. The Access session has the
information about who the current User is and what Groups he belongs to. This
is compared to the information in the file being opened to see if adequate
permissions exist. If they do the file is opened. If not then an error is
raised and the file doesn't open.
Point 6)
What is an "unsecured file"? Basically a file is unsecured if the default user
Admin has full permissions to it or the default group Users has full permissions
to it. Such a file doesn't care what User attempts to open the file as ALL
users are members of the default group Users. This is true of all workgroup
files. You cannot create a user account that is not a member of the default
group Users and the group Users is identified exactly the same in every
workgroup file.
I know the above is rather verbose, but the main point is that User-Level
security is not "attached" to a particular file in the sense that a simple file
password is. You run Access in an environment that is determined by your
workgroup and that environment will let you open some files and not others.
There is no marriage between the MDW and the MDB since any MDW can be used to
open an indefinite number of MDBs and any MDB can be opened by an indefinite
number of MDWs.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
| 
