While I needed this to create a report that enabled us to be able to see whether a database was being used at all, I can see other uses this might be put to. It could be part of a detailed billing effort, or it could be used where you need to double-check who is, and in the past has, actually accessed what, as part of a security and access control audit.

NotesUnreadMarks
How many times have you wanted to be able to play about with the unread mark tables in a database? This class, yet again written by Daniel Alvers, enables you to do just that. But you should be cautious with it. Daniel wrote this for R4, and while it seems to work with R5, remember, as he points out in the Notes.Net reviews, that the way that the R5 client manages unread marks means that using this concurrently with client sessions just won't give you what you need. Indeed, the class was not intended, and should not be used from the UI (User Interface). Also, be aware that unread marks don't replicate with the database between client and server or between server replicas, rather they're stored locally in desktop.dsk and synchronized with replicas when they're opened.

As described in the Notes C API reference documentation:

In Notes, unread marks for each user are stored in the client desktop.dsk file and in the database. When a user closes a database (either through the Notes user interface or through an API program), the unread marks in the desktop.dsk file and in the database are synchronized so that they match. Unread marks are not replicated when a database is replicated. Instead, when a user opens a replica of a database, the unread marks from the desktop.dsk file propagates to the replica database. NSFDbGetUnreadNoteTable only accesses the unread marks stored in the database and does not attempt to synchronize with the unread marks in desktop.dsk.

But even so, there are instances where I can see this being useful in background activities. If you're performing some administrative actions on a database that will involve updating documents, it'll mean that all users will see all the documents you change marked as unread. You could use this class to make a list of who has read what and then update the unread lists afterwards. You'd need the NotesUserActivity class to be able to list all the user names that have accessed the database and therefore for whom unread mark table entries exist.

I can also see it being useful in agents that inform people of document updates in databases. Normally you'd do this with an agent that runs on new and modified documents, but when you alter such an agent, it then works on all documents in the database. In fact, what happens is that the agent runs on all documents that are now modified since the agent's last run. Change the agent and the last run information is deleted, so it processes all documents in the database. If what you're doing is sending newsletters to people telling them of new documents, the end result will be less than useful. With this class, you could genuinely tell users individually about documents that they have not read, or which have changed since they last read them.