Dan,
Another way to address this is via user roles. This is a little more
complicated, but provides a lot more flexibility. In many of my databases, I
add three tables (tblUsers, tblRoles, and tblUserRoles) and a form (frmUsers)
which allows me to assign roles to the applications users. These roles
determine which forms and reports a user can access.
In the applications Splash screen, I check to see what the Windows userid is
of the person that is running the application. If that userid is not already
in tblUsers, I add it to tblUsers and add a record to tblUserRoles (for the
most restrictive role in tblRoles). If they want or need a greater level of
access, I provide a way for them to email the application administrator a
request to the various roles.
Then, after checking the usersid, I enable or disable the buttons on the
switchboard based on thier role(s).
Another way to do this, without disabling any of the buttons on the
switchboard it to use the Form/Report Open event to check whether the current
userid is assigned to one of the roles required for access to that
form/report. If not, all you have to do is cancel the Open event. Another
option with this method would be to open the form, but hide the controls that
you don't want them to see on the form or report, (you could do this in the
Load event of the Form or Report).
--
HTH
Dale
email address is invalid
Please reply to newsgroup only.
