This option is set from the Profiles tab of the Options Manager interface.

Discus and Discus Pro record, in the user database, the "last access" time of a user. This is used to display information in the User Manager, and in Discus Pro, as a basis for filtering the User Manager list based on access time and for display in the user interface member list.

To record a "last access" time in the user database, Discus must perform an update of that database whenever a user accesses the board (to record the new time).

If a MySQL database is used with Discus Pro, the update operation is quick and safe, as database systems such as MySQL are optimized to store large quantities of information and to allow this information to be updated easily. However, if a flat text file is being used, to update the one bit of information (user access time), it is necessary to read the user file into memory, make the manipulation, and write the user file back out. Continuous reading and writing of the user file in this way makes it susceptible to corruption in the case of a server crash.

Writing to the user file has another disadvantage - each write requires that the user database be locked. While the database is updated to record a last access time, no other processes can access the user database at this time. It is for this reason that a "File Locking Error" on the users.txt file may be frequently seen on busy boards with many members.

This setting allows you to control how often your user database is updated with the user's access time. The issue here is a tradeoff between accuracy of the "last access" time and speed and reliability of your board (improving performance by reducing the number of file writes).

• Upon each access: Each time the user's password is validated for any reason, the last access time is recorded. This could be many hundreds or thousands of times in a browser session, if the user previews and posts several messages and performs searches. This is most accurate because it records the access time whenever possible, but least efficient because it causes the board's user database to be written and rewritten the most.

• Whenever username and password are manually entered: As the option says, when the user types in their username and password into the board, or has this information automatically filled in by a cookie, this is counted as an access. This is a reasonably accurate measure of user access to the board, and it can improve the performance.

• Upon first access to board in session: If Discus can detect that a user has already accessed the board in the same browser session, the update will not be performed. You can use this option to catch the time that a user first logs in within a session, but it will be off by quite a while if the user is on your board for a long time. This substantially improves performance but is not very accurate.

• Never: Discus will never record the "last accessed" time in the user database. This is the most efficient, since no database updates are ever performed, but it does not provide any tracking whatsoever for user access times. This option is recommended only in the case that you are sure that you will never have a need to see who is accessing your board, and when. In practice, this is not recommended.

If you are using Discus Pro and have the MySQL database back-end enabled, this option will not appear in the Options Manager. Because MySQL is so reliable and fast at making an update of user information, the equivalent of "Upon each access" as noted above is performed. However, this will not create much additional load on the server, and will not result in file locking errors, since MySQL is designed to accept and manage multiple connections to the same database.