Problems with Unread marks
Bård Andersen
we did this, the unread marks are not the same as before. Some mail that
have been read are marked unread and som unread mail are marked as read,
but their is no sence in the way it's done.
So is there anybody out there that have anny ideas of why and what can i do
about it.
We run on a Notes 4.5.5 enviroment and the moving whas done by copying from
NT.
Regards
Bård Andersen
Stephan Best
we have the same problems in our company.
It is a known bug, you can read it in the Lotus Knowledge Base.
The unread marks are not replicated correctly ;-(
Regards,
Karin Delp
Lotus Notes Administration Merck KGaA
Raymond Neeves
How Do Unread Marks Work in a Notes/Domino 4.x Environment?
Notes 4.x tracks the Unread documents in a database in two ways. In the
database (.NSF) file itself, an Unread ID table is stored. This table
tracks the documents each user has Read and contained within the .NSF
file, which is generally held on a server. In addition, the CACHE.DSK
file on the workstation tracks a history of Read/Unread events for the
individual workstation. This journal is used to track the documents
Read across multiple replicas from a single workstation and will keep
track of the last 20,000 Read/Unread events. This journal is
workstation-specific and may contain events for multiple users.
When a user opens a database, the Unread ID table is cached in the
DESKTOP.DSK file. During the opening process, the CACHE.DSK journal is
applied to this Unread ID table and the table is updated accordingly.
While the user accesses the database, all updates to the Unread ID table
happen locally. When the database is closed, the ID table is sent back
to the .NSF file on the server.
The Unread ID table is updated in several ways. First and foremost, the
ID table is updated as a user opens a document. Second, as a user
accesses a replica database, the workstation "plays back" the journal
stored in the CACHE.DSK and updates the table. Third, when dealing with
a local replica of a database, the Unread ID tables can be synchronized
during replication if the workstation's NOTES.INI file uses the
setting, REPLICATOR_SYNC_UNREAD. This setting should equal the minimum
number of hours Notes should wait between replication events before
exchanging the Unread marks between replica databases. Fourth, while
replica icons are unstacked from a workstation's workspace, a user can
issue the menu command, Exchange Unread Marks. This can be issued using
@Command([ExchangeUnreadMarks]) in a SmartIcon or by selecting Edit,
Unread Marks from the menu.
NOTE: The REPLICATOR_SYNC_UNREAD parameter for the NOTES.INI file is
functionality added in Lotus Notes Releases 4.13 and 4.51. Prior
releases of Notes do not support this setting. In Lotus Notes Release
4.5.5 and Release 4.6.2, the REPLICATOR_SYNC_UNREAD parameter can be set
to -1 (negative one) and Unread marks will be exchanged upon every
replication event. In Notes R4.x, this setting will initiate the
exchange of Unread marks between all replica databases on the
workstation. The support for automatic exchange of selective databases
is currently under consideration by Lotus Development.
IMPORTANT NOTE: Using the REPLICATOR_SYNC_UNREAD parameter will result
in severe performance degradation when replicating. Support for this
NOTES.INI variable may be removed in future feature releases if this
feature is enabled differently.
JOURNAL PLAY BACK:
The 20,000 events that are stored in the journal are consecutive
events. Note that because the journal retains the last 20,000 events,
it is possible that this play back function would not synchronize all
the Unread marks between two replicas. This function is the main way in
which Notes tracks Unread marks from server to server. While using a
single workstation, a user's Read/Unread events from replica to replica
across all servers are stored in this journal.
For example, a user accesses the Public Name & Address Book (NAB) on
ServerA and marks all the documents Read. As this user opens the NAB on
ServerB, the journal plays back against the Unread ID table on ServerB
and the Unread count should reduce to zero. This will happen if there
are not any additional documents in the replica on ServerB. Obviously,
new or modified documents on ServerB will still show as Unread.
Note that there is a limitation of 20,000 events that this journal will
track. While Notes stores this information intelligently enough to
remember more than 20,000 individual events, it is possible that this
journal will "forget" events before they are played back against an
appropriate Unread ID table. In other words, marking all 40,000
documents in a database Read will still work against another replica
even though there are more than 20,000 updates.
Another instance where this journal can "forget" Read/Unread events is
if there are two users using the same workstation. As a database is
opened, the journal updates the Unread ID table for the database being
opened. To increase performance, the journal updates the events only
for a specific user since the last time the database was opened. So if
one user marks documents Read on one server, and a second user opens a
replica of that database on another server, the first user's updates
will be "lost." Removing and re-adding the database icon from the Notes
workspace should alleviate this, because adding a new icon to the
workspace forces the entire journal to be applied to the database in
question.
Related Documents:
Are Unread Marks Fixed in Release 5?
Document #: 169936
the r5 document is interesting as well and explains why moving a
database from one server to another can destroy the unread document tags