Under the MSAccess forum, I have a couple of posts on how to easily retrieve the user LoginID (I attached it here.). You could easily set up a table with 2 fields, LoginID and Password. This would save the user having to always enter their LoginID (which would become a pain for them).
What I actually do is have several tables of permissions with a LoginID field for specific permissions on what the user can do. If the LoginID is in the AdminMaintenance table, they can edit the Maintenance menu, If their loginID is in the AdminLookup table, they can edit lookup items, etc.. I think the example in the attachment shows you how you can do something like this (look at the function isadmin() under the Check For Admin Module - the form also gets you started). You could have several "admin" type tables and other functions like isadminlookup, isadminmaintenance, isadmindelete, etc...or get even fancier and have a table which has the loginID and the type admin service and some basic/fancy modifications to the code where you call a certain function depending on what the user is trying to do and if it's listed in the type admin service table...it can probably get even fancier but you have the option of doing it several different ways. I've used this technique quite a few times and it's worked out pretty well for me. Others on this site though might have some different suggestions they've done in regards to security and so on.
Personally, I dislike a program where you have to put in your username and password each time to get into the program and then also to get into certain forms (they've already logged into Windows and if you don't want them to use this program, just do a comparison of the loginID with the admin table(s) in the onopen event of the MainFormBackground.) Either that or assign permissions at the file/mdb level.
One last note: You'll notice that I have a modal form (modal type under the properties) (getuser - don't confuse the form name with the function getuser()) and a MainFormBackGround form. You must close the modal (getuser) form first and then close the MainFormBackground where you would add your login to the dbo_adminTable table. Utilizing a pop-up modal form with a Background form (that is maximized) is a nice way of keep users from using the upper menu system and gives you certain control over who can get "Behind the scenes" to see the tables. The onload code takes care of the right-click to design mode on the form. Most users aren't familiar with the shift key to bypass code and most also won't know some of the other tricks to get behind the scenes but if you wanted to, you could protect your app even further. This is just a quick, down and dirty, easy way of doing it and I'm not sure if it has any minor holes or not. Having an Admin close type of button on the Main Form where I close all the forms including the background form if it sees certain loginIDs or my loginID helps out a lot.
You also need to include the other class modules for the getuser function to work. You'll notice there are some other neat things you can do on objects from looking through the class modules.
And another last note: You can utilize the =getuser() function almost ANYWHERE, including a field on the form maybe called: EnteredBy where the default value is =getuser() (in conjunction with a DateEntered field which defaults to =date() - or in a query to see who entered what or as an expression, etc, etc... --- EnteredBy and DateEntered are what I would call some standard fields to have in your most important tables of information or anything you'd want to track entries on.
I'm sure you'll get some different suggestions on how you want to do it.
Attached Files GetUserAndPermissionsSample.zip (516.5 KB, 1 views)
Last edited by pkstormy; 09-05-06 at 22:29.
Expert Database Programming
MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)