Description ...
This is an update to the utility originally posted here. The utility will log the users who are connected to an MDB/E or ACCDB/E file via the UserRoster feature of the Jet/ACE database engine implemented with the introduction of Access 2000. In addition, the utility can manage the Connection Control (aka: Passive Shutdown) property for the database file being monitored.

The file format of the utility is Access 2000. However, as indicated, All Jet/ACE formats from Access 2000 and forward can be managed as long as the correct OLE DB Provider for the Jet/ACE engine is installed.

When to use it ...
- Use to log who has/is connected to your datafile.
- If you set it to "AutoRefresh" at a given interval along with the "Update Records" option, you can find all the users that have logged on and when they logged off.
- You can use it to figure out who was connected to the datafile when the database goes "corrupt"
- I have found the app quite useful in tracking usage levels during the day and which computers are using my datafiles.
- To manage the Connection Control property (Passive Shutdown) on database files. The Connecton Control property, when enabled, prevents new connections, thus allowing your connection count to shrink passively.

How to use it ...
1. Download and unzip the file, then open the file in Access 2000 or higher.
2. The interface form opens automatically (frmConnectedUsers)
3. Browse for the .MDB/E .ACCDB/E file you want to monitor or examine.
4. "Refresh" the list of connected users as needed via the Refresh button or toggle the AutoRefresh option.

Upon selecting a file, the code will interrogate the file and extract the Computer Names and User names that are connected (aka: have the file open). Subsequent interrogations are invoked via a command button or the AutoRefresh option. The results of the interogation are stored in a local table (tblConnectedUsers)

Options available when using this utility. (Some are static between sessions and stored in the local table named tblSettings.)
- You can set an "AutoRefresh" rate which will run the analyzation at a given interval (uses Form_Timer)
- You can DELETE, MODIFY, or APPEND the records in tblConnectedUsers upon each "Refresh" attempt.
- You can either keep the connection object to the datafile static (aka: means you don't have to reconnect to the MDB after each Refresh ... this is MAY be helpful in finding the user who causes your database to go corrupt!)
- You can select to record either the Access Workgroup Username or the Windows User name.

Data that is recorded in tblConnectedUsers ...
RecordID - AutoNumber
ComputerName - The computer name that was connected to the datafile
UserName - The id of the user from the .MDW file on the ComputerName (typically Admin) (aka: Access User Name) --- OR --- The remote computer's Active Directory logged in userId (aka: Windows User Name). This is a user selectable option.
Connected - Is the User Connected (will only show No/False if you have the Update Records option set)
SuspectState - If the user has left the database in a "SuspectState" will show true, otherwise NULL

Notes and Cautions ...
- You should not have mulitple instances of this app open, unsless you change the name for each instance. For example: you should not have two instances of "WhoIsConnected.mdb" on the same machine, however, you can copy and rename the app as much as you want and open each copy, even on the same machine: "WhoIsConnected_1.mdb","WhoIsConnected_2.mdb","WhoIsConnected_3.mdb". The reason for this restriction is that the data collected is stored in a local table, plus many of the settings are stored in a local table so if multiple instances of the same mdb are created, conflicts will arise.

- Permissions or other IT related configurations may prevent the code from reading the Windows User name.

- I have not tested this utility on a CORRUPT database. The option of keeping the connection to the datafile as a "STATIC" object (controled with the "Force a New Connection" option), should maintain the "Connection" to the datafile and allow an analyzation of the UserRoster when/if the datafile goes corrupt during the monitoring process. I did not have a database go corrupt during the time I was monitoring it ... so ... well there you have it ... I hate to "Release" an app that has not been completely "Tested" ... but I just could not get a datafile to become corrupt while I was monitoring it ... go figure!

-----

Here it is ... Enjoy ... and PLEASE send me any recommendations for improvement or notifications of bugs. Also, if you "track this topic" (under the Options button) with email notification, you will be notified of updates and other postings on this thread topic regarding this utility

Edits:
Attachment updated on 2012-03-21 (datAdrenaline)