Reflecting on this Chapter

If you look back on the chapter, you may conclude that you now have a number of ways to monitor your users ”and that is certainly the case. The reality over time, however, is that these techniques end up being very useful management tools for assisting you with database management and for reviewing possible software changes, be they for security reasons or just normal improvements. So let's review how you can put in place some of the topics and software discussed in this chapter.

Sometime before you start getting more sophisticated with security and the ensuing issues, like training your users how to do things in a more secure application, it certainly may be worth undertaking surveying your database to find out whether you actually have a problem in the first place. In the first instance, I would recommend that you import the frmJetUserRoster demonstration form into your database to view computer and Access workgroup logon names . This form allows you both to assess the number of users in a database and to understand who is using the database. If you have a large number of databases, you may want to use a tool such as LDBView or the Access Workbench to view this information in any of your databases. Once you have these tools working, you will probably use them to help manage the database for administration issues, such as asking users to log off the database for database or network maintenance and upgrades.

In larger networked environments, the value of the computer names supplied by the Jet User Roster may not be all that useful. At this stage, I find it more informative to use a customized logging system in the database to capture and store the details. This system has the advantage that the UserLog table can store the Windows user IDs plus creates a good record of who has used the database. The Window user ID and the time that the user opened the database are very useful for managing the database users.

Finally, as I explained in the chapter on startup options (Chapter 2), it is possible for users to open your database and skip your startup form or AutoExec macro, and thus, no UserLog entry is generated. The frmFindNoStartups form in the Access 2000 demonstration database can identify this possible security breach.