you need a table of users (tblUser) with all of the user attributes as fields. To exert control, one way is to cross reference their profile/level in this table against a table of permissions, but there might be as many ways you can do this as there flakes in a cereal box. There are determining factors, such as, will this be based on controlling who gets to open a particular form or report? Then it could be as simple as providing a form with command buttons, some of which you hide when the form opens, based on their profile. How to know what this profile is can be as simple as opening a form hidden (when db is opened) and storing the user info, storing that info in an environment variable (see Environ) or as complicated as creating a user object to which you assign any property that you think you might need (e.g. EmplNo, Level, emlAddress, FName, LName, etc.). When they try to open a form, your code checks the Level (permissions) property based on their login info. BTW, I stopped worrying about passwords long ago. Using their Windows login ID, my db looks to see if they're in the users table. If not, they don't get in. I never had to worry about anyone asking for a password reset because they forgot it, nor did I have to worry about it being discovered. Research fosUserName.
Or is it a little more complex, such as allowing a form to be opened by all, but editable by only some? Then your code opens the form in a manner that restricts editing, such as using a dynaset recordset or locking or disabling all the data input controls? You'd need to loop through them and based on the profile, lock/disable or don't. Obviously you don't disable a close button, so the loop can either 'disable by control type', or by looking at the control tag property (which you've assigned a value that makes the control part of a group that can be disabled and your code checks for that value).
Or is it much more complex, such as controls on a form to be editable, but not others? Looping through form controls is the only way, AFAIK.
What's not really a good idea is to have a table with a field for every report, form, or function that you use checkboxes for to restrict access. Add a form, and you have to add a table field. This isn't a good design practice. It would be more proper to have a table where the settings are listed in rows (records). Although this means that if there's 5 forms, each user has up to 5 records whose settings allow or don't allow then to open a given form/report. Might be lots more records, but it's the right approach if it fits your plan, since to add a new form or report only requires the addition of a new record. Note that I said "up to 5 records". You can also only add a person's id and a given form name (and maybe what permission they have) if you want to provide access to it. If they're not listed for that form, they don't get to open it. This would be a more correct way of listing accessibility.
As I said, lots of things to consider, and several ways to accomplish pretty much any of them. Of course, your db must be split, and each person uses their own fe (front end) copy.
