Document count different in replicas

I have come across a strange problem. We have clustered environment and I run an agent to compare the document counts between the replicas on both servers. Just lately I have noticed on users who are using the version 6.5.1 mail template the document count is reporting a different number to the actuall number of docs in the db. Eg the front end server gives one number the backend server gives a different number. On investigations to correct the differences to ensure data integrity it is found that if you go into the db and select all the documents they will give a third number and this number is the same in both replicas, indicating that the replicas are in fact up to date.

This is beginning to cause some grief as we are about to roll out more of the user base to the 6.5.1 template and there is a lot of manual checking to determine if the replicas are in sync.

Has anyone seen this problem where doc count is different on the properties to what is in the db? I have read a few suggestions about creating select all views and response docs causing the problem but I am not entirely convinced. I don’t want to be adding additional views into users mail files.

Regards,

Mark

Subject: Document count different in replicas.

We have found the problem.

A known bug. Good news is, it is fixed in 6.0.4 / 6.5.2.

Title: Fix List for Lotus Notes and Lotus Domino Releases 6.0.4 and 6.5.2 Maintenance Release (MR)

Doc #: 7005147

URL: http://www-1.ibm.com/support/docview.wss?rs=899&uid=swg27005147 LotusScript BHIR5MYVA4 SPR# BHIR5MYVA4 - Fixed a problem where the LotusScript NotesDatabase.PercentUsed property returned invalid values if the database was over 2 GB in size.

It not only affects Percent used but also the doc count property.

Subject: RE: Document count different in replicas.

There is actually no view in a mail file that displays all documents, so you could expect this count to be less than what your agent will find.

The database properties will show the actual number of documents in the database. You don’t need an agent. Your agent might not have read access to all of them, resulting in a lower count. The server might not have read access to some documents, making the server unable to replicate them.