I am looking for someone to guide me like that i have a DB and i have 4 users on it i want to create each user name with password and with different user access level for forms and reports. i need one more thing that when any user get print of any report so that the login name (User name) to be displayed in report footer.
Login and User Name (1 Viewer)
- Thread starter syedadnan
- Start date
- Local time
- Today, 16:15
- Joined
- Feb 28, 2001
- Messages
- 27,188
IF you are in a domain-based environment with users sharing the back-end of a split database, you need to look up (web search) the Access "Environ" function to see how you could find out your user's login name. If you are in a domain environment, I wouldn't worry about the passwords because the domain security will be a LOT tighter than anything you could implement with VBA.
If this is NOT a split database with front-end/back-end separated, you are in danger of inviting corruption.
If this is NOT a domain-based login environment then your security will be problematic at best, because Access by itself isn't that secure any more.
Let us know more about your network environment.
Oh, one more thought comes to mind... you COULD do this via a single machine that is used by your four users one at a time, in which case the Windows login would be secure enough to again avoid the passwords and to support the Environ function. However, this situation potentially has other, far bigger security headaches.
If this is NOT a split database with front-end/back-end separated, you are in danger of inviting corruption.
If this is NOT a domain-based login environment then your security will be problematic at best, because Access by itself isn't that secure any more.
Let us know more about your network environment.
Oh, one more thought comes to mind... you COULD do this via a single machine that is used by your four users one at a time, in which case the Windows login would be secure enough to again avoid the passwords and to support the Environ function. However, this situation potentially has other, far bigger security headaches.
Thanks,
Your last para is relevant to my requirement like my all four users will use same pc with different login and password now i want that is that to be done with access login passwrd through table or windows ?
- Local time
- Today, 16:15
- Joined
- Feb 28, 2001
- Messages
- 27,188
In this case, you are going to have to do some things carefully. You (or the machine's administrator) will have to create a folder in which you would place the database files. You CANNOT just create the folder yourself unless you have admin rights. By default, the folders would be part of your profile, and that isn't what you need.
The next thing is that you need to do advanced security settings to give you and the other three users MODIFY level of access to that folder, any child folders of it, and all the files therein. In a domain, it would be incredibly easy - but in a standalone system, you have to more or less violate some principles of good security.
Here is what I would do. If you know how to do this, great! If not and if someone can help you, this is the PREFERRED way to do this: Create a local machine group with a name that makes sense - like UserOfDBX - but it could be an internal project name or an arbitrary name too. Give this GROUP the ownership of the folder and files plus MODIFY access to the folder, files, and child folders. (Your security person might know this as "propagate permissions.") Then grant membership in that group to the four users. You will, of course, need to allow SYSTEM to have FULL CONTROL permissions. Nobody else should even have READ access, which means that you remove any entries other than the group and system permission references. You expressly do not want to allow AllUsers or Everyone (two intrinsic Windows group names) to have access.
OK, with Windows now running interference for you, the next step is to determine who is using the database and what they are allowed to do. Access WILL NOT enforce this automatically. You are going to have to build this into your system. Which means your users cannot be allowed access to the Navigation panel. Everything they do must go through a Dispatcher or Switchboard form. You can look up "Securing Access 20xx" (where you supply the last two digits corresponding to your version of Office) to see about disabling/hiding the ribbon.
I recommend that since you are sharing this and will probably have to do maintenance on this beast, such as fix bugs in forms or add a new report, etc. etc. that you look up how to SPLIT the database into a Front End and a Back End (FE and BE). The FE will be what you run. Put the BE in a child folder of the one in which the FE resides. Then used Access Linked Table Manager to point the FE to the BE's tables.
This in turn means that you will have to keep a "design master" copy of both FE and BE in a separate folder so that you can at some point REPLACE the FE with a new one (and repoint the FE to the production BE).
Finally, a bit of safeguarding. If this is important enough, you will want to set aside some time to do regular backups of the given folder on this system. If the machine takes a nose-dive, you want to not lose any more than you have to.
Next step: You have built the switchboard... (or WILL build it). This becomes your "Opening Form" and will run as soon as Access launches. This form's event routines will be your security watchdog. I recommend that even though you have the form's Class Module available to you, and cannot avoid using it for event management, you should have a separate General Module for your security code AND DATA. At the appropriate events on the Switchboard form, you call the security code to define or test the data regarding who is running.
This implies a table for users that shows the login username, which is what Environ("Username") gives you. Look up what you need to know from that table - and that means that only the person who controls the application - you - should have the ability to update it. And that means a User Control form that uses the security code and honors the security you are implementing for the OTHER forms and reports.
The reason I suggest a General Module is that you can declare Public variables to remember your username, role, rights, whatever. Then the OTHER controls of your switchboard will be able to test whether the current user has the particular rights needed for this. As to exactly HOW you want to implement this, it might be as simple as defining a test of the username itself using a SELECT CASE statement.
Where you implement these tests is important. Remember that a switchboard form is a form. (No, not a tautology but a statement of membership in a group of similar items.) If you want to stop a person from opening a form, you put code in the form_Open routine and if they are not authorized, you CANCEL the Open. If you DON'T use the Cancel option, the form WILL open. So for the switchboard, you see if the logged in person is in your table and if not, do a CANCEL. For the individual functions, if you determine the user is not authorized for the form, then in THAT form's Open routine you do the Cancel.
If this doesn't make you stop and think for a while, then I have overwhelmed you badly. But this is how I would approach what you said you wanted to do. After this, it is all in the details.
The next thing is that you need to do advanced security settings to give you and the other three users MODIFY level of access to that folder, any child folders of it, and all the files therein. In a domain, it would be incredibly easy - but in a standalone system, you have to more or less violate some principles of good security.
Here is what I would do. If you know how to do this, great! If not and if someone can help you, this is the PREFERRED way to do this: Create a local machine group with a name that makes sense - like UserOfDBX - but it could be an internal project name or an arbitrary name too. Give this GROUP the ownership of the folder and files plus MODIFY access to the folder, files, and child folders. (Your security person might know this as "propagate permissions.") Then grant membership in that group to the four users. You will, of course, need to allow SYSTEM to have FULL CONTROL permissions. Nobody else should even have READ access, which means that you remove any entries other than the group and system permission references. You expressly do not want to allow AllUsers or Everyone (two intrinsic Windows group names) to have access.
OK, with Windows now running interference for you, the next step is to determine who is using the database and what they are allowed to do. Access WILL NOT enforce this automatically. You are going to have to build this into your system. Which means your users cannot be allowed access to the Navigation panel. Everything they do must go through a Dispatcher or Switchboard form. You can look up "Securing Access 20xx" (where you supply the last two digits corresponding to your version of Office) to see about disabling/hiding the ribbon.
I recommend that since you are sharing this and will probably have to do maintenance on this beast, such as fix bugs in forms or add a new report, etc. etc. that you look up how to SPLIT the database into a Front End and a Back End (FE and BE). The FE will be what you run. Put the BE in a child folder of the one in which the FE resides. Then used Access Linked Table Manager to point the FE to the BE's tables.
This in turn means that you will have to keep a "design master" copy of both FE and BE in a separate folder so that you can at some point REPLACE the FE with a new one (and repoint the FE to the production BE).
Finally, a bit of safeguarding. If this is important enough, you will want to set aside some time to do regular backups of the given folder on this system. If the machine takes a nose-dive, you want to not lose any more than you have to.
Next step: You have built the switchboard... (or WILL build it). This becomes your "Opening Form" and will run as soon as Access launches. This form's event routines will be your security watchdog. I recommend that even though you have the form's Class Module available to you, and cannot avoid using it for event management, you should have a separate General Module for your security code AND DATA. At the appropriate events on the Switchboard form, you call the security code to define or test the data regarding who is running.
This implies a table for users that shows the login username, which is what Environ("Username") gives you. Look up what you need to know from that table - and that means that only the person who controls the application - you - should have the ability to update it. And that means a User Control form that uses the security code and honors the security you are implementing for the OTHER forms and reports.
The reason I suggest a General Module is that you can declare Public variables to remember your username, role, rights, whatever. Then the OTHER controls of your switchboard will be able to test whether the current user has the particular rights needed for this. As to exactly HOW you want to implement this, it might be as simple as defining a test of the username itself using a SELECT CASE statement.
Where you implement these tests is important. Remember that a switchboard form is a form. (No, not a tautology but a statement of membership in a group of similar items.) If you want to stop a person from opening a form, you put code in the form_Open routine and if they are not authorized, you CANCEL the Open. If you DON'T use the Cancel option, the form WILL open. So for the switchboard, you see if the logged in person is in your table and if not, do a CANCEL. For the individual functions, if you determine the user is not authorized for the form, then in THAT form's Open routine you do the Cancel.
If this doesn't make you stop and think for a while, then I have overwhelmed you badly. But this is how I would approach what you said you wanted to do. After this, it is all in the details.
