User access 2010 (1 Viewer)
- Thread starter syedadnan
- Start date
This is an over simplified explanation to get you on the way..
First you need a log in form to recognise which user is logged in. Have the database open into this form using the auto exec. Hide the nav bar, to avoid people by passing the form. There are many ways to build a log in..again a simple way would be to check if the user name and password both equal the values in a "contact" table. Have a field in the contact table with the admin level , use a number. Use an "if ..then" function on a button to open the form you want if the credentials are correct.
use the on current event of the input form to check the admin level in the log in form. Use "if ...then" to either enable or disable the fields depending on the admin level.
i.e
if forms!LogIn!AdminLevel = 1 then
Field1.=true
field2.enabled=true
end if
etc,etc
The case select function may be better, or you can use the "tag" property of each field and loop through them enabling or disabling as necessary.
have a play...
First you need a log in form to recognise which user is logged in. Have the database open into this form using the auto exec. Hide the nav bar, to avoid people by passing the form. There are many ways to build a log in..again a simple way would be to check if the user name and password both equal the values in a "contact" table. Have a field in the contact table with the admin level , use a number. Use an "if ..then" function on a button to open the form you want if the credentials are correct.
use the on current event of the input form to check the admin level in the log in form. Use "if ...then" to either enable or disable the fields depending on the admin level.
i.e
if forms!LogIn!AdminLevel = 1 then
Field1.=true
field2.enabled=true
end if
etc,etc
The case select function may be better, or you can use the "tag" property of each field and loop through them enabling or disabling as necessary.
have a play...
jonathanchye
Registered User.
- Local time
- Today, 04:17
- Joined
- Mar 8, 2011
- Messages
- 448
You should have a table for users. Something simple like txtUsername, txtPassword and txtAccessLevel.
You then create a module with a function like GetAccessLevel.
Finally on each control in your form you can then use the form's OnLoad event.
As a pseudocode for OnLoad, if GetAccessLevel = "Admin" then Me.Textbox1.locked = false.
You then create a module with a function like GetAccessLevel.
Finally on each control in your form you can then use the form's OnLoad event.
As a pseudocode for OnLoad, if GetAccessLevel = "Admin" then Me.Textbox1.locked = false.
- Local time
- Yesterday, 22:17
- Joined
- Feb 28, 2001
- Messages
- 27,302
This is not trivial.
First, you can NEVER allow users to see the database objects individually. You need some kind of switchboard form or dispatcher or whatever you wish to call it.
Second, you need to be on a domain where authentication is external to your local workstation (because otherwise someone could just lie about who they are)
Third, EVERY FORM that you open through the dispatcher has to be coded to recognize the roles that individuals could possibly play.
What you want to do is not impossible but the more complex the app, the more tedious it will become to maintain this kind of control. I helped myself to do this by defining some "prototype" forms - one for bound forms and one for unbound forms - that implemented some of the security checks in the prototype "event" codes. Things like the FORM_OPEN, FORM_LOAD, FORM_CURRENT (for bound forms), FORM_CLOSE, etc. I also implemented common command buttons like COMMIT, CANCEL, CREATE, REMOVE, etc. for the various functions that were possible in the form.
The trick here is to keep everything meticulously updated. If you have a bug in one form's FORM_OPEN routine, odds are pretty good it would be everywhere that your prototype was used, so you cannot "let it slide" to fix it for ALL affected forms. The overhead is higher as the number of forms increases. It's just a cost of doing business, I'm afraid.
First, you can NEVER allow users to see the database objects individually. You need some kind of switchboard form or dispatcher or whatever you wish to call it.
Second, you need to be on a domain where authentication is external to your local workstation (because otherwise someone could just lie about who they are)
Third, EVERY FORM that you open through the dispatcher has to be coded to recognize the roles that individuals could possibly play.
What you want to do is not impossible but the more complex the app, the more tedious it will become to maintain this kind of control. I helped myself to do this by defining some "prototype" forms - one for bound forms and one for unbound forms - that implemented some of the security checks in the prototype "event" codes. Things like the FORM_OPEN, FORM_LOAD, FORM_CURRENT (for bound forms), FORM_CLOSE, etc. I also implemented common command buttons like COMMIT, CANCEL, CREATE, REMOVE, etc. for the various functions that were possible in the form.
The trick here is to keep everything meticulously updated. If you have a bug in one form's FORM_OPEN routine, odds are pretty good it would be everywhere that your prototype was used, so you cannot "let it slide" to fix it for ALL affected forms. The overhead is higher as the number of forms increases. It's just a cost of doing business, I'm afraid.
