This problem arose during migration of an application – that probably started life in version 5 of Notes and which has moved through to the latest 8.5.2 release with various stops on the way. My first thought was that it was some esoteric formula that I had used but on consideration I was fairly sure that I had not used either of the ones referenced. After research which dredged up only references to Notes 5 – I began to be suspicious about the state of the database copy that had been carried in in preparation for stripping this application back – for web only access to its archive information. Specifically – had the server completely finished creating views and records.
A test of copying the database on the server itself proved a) much quicker and b) to have the correct number of records expected in the copy. Comparing this with the copy “backed up” from within a remote notes client and I noted a trickle of updates that were slowly heading towards the same number of records. This meant that there were likely to be inconsistencies in the indexes until the full number of records had copied. This got me thinking about what forces the indexes to be rebuild and went off to research that. The error still persists even in the server copied version – so I’ll update when the source of the error is found – but my approach is going to be to force the views to rebuild by adding addition fields.
|From IBM I got this … http://www-01.ibm.com/support/docview.wss?uid=swg21090329
|When Lotus Notes®/Domino® rebuilds or refreshes indexes, it takes up considerable resources on a server. Running Updall can rebuild/refresh indexes, but what else causes indexes to be rebuilt?
|For general background information, refer to the document titled “Updall switches, Update and NIF – Notes indexing basics” (#1085954) for a description of how the Notes Indexer functions.
Indexes will not be discarded unless they have not been accessed. You can override this setting by adding the NOTES.INI variable
Notes/Domino can also trigger indexes to be rebuilt or refreshed due to a number of other reasons, outlined as follows:
1. Design changes to a view
The index will be rebuilt if changes are made to selection formulas or column formulas. Cosmetic design changes such as column width or heading changes will not trigger a rebuild.
2. View is corrupted
If a view is detected as corrupted, Notes flags that view to be rebuilt. The view will not be rebuilt until all users have logged out of the database and either an updall -r is run or when a user opens the database for the first time and accesses a particular view after all users have logged out. You will be able to tell that an index is corrupted because the users that are still in that view will receive errors indicating that the view is corrupted. You should also notice such errors in the log file.
After a database has replicated, the views will need to be incrementally updated to take account of the changes made. Notes also updates any databases that have full text indexes with the Index Update Frequency set to “hourly” or “immediate”.
When agents that add or delete documents are run on a database, the index for that database will be incrementally updated. If the agent modifies documents, all built views will be checked, but only the affected ones will be updated.
5. Changes in the collation table
The collation table tells Notes how to sort things. If the collation table changes, then NIF must rebuild every collection. The collation table is stored in the CLS files that ship with Notes. If you upgrade to a different version of Notes, it is possible that it will contain a different collation table and therefore force a rebuild of every collection the first time they are opened. Another way to change the collation table is via the menu option ToolsSetupUserInternational. That will bring up a dialog box with some collation choices. If you choose a different collation method here, all collections will be rebuilt when opened. Once a collection has been rebuilt with the new collation table, the version of the collation table is saved with the collection so NIF knows when the collation table changes.
When the Router deposits a message in a mail database, it also places a corresponding request into the Update queue, which will cause the respective view to be updated.
7. Other causes
Pressing SHIFT+F9 rebuilds the view you are currently in. Pressing CTRL+SHIFT+F9 updates all views in the database you are in.
NOTE: It does not matter if the views are hidden or open. Pressing CTRL+SHIFT+F9 will rebuild views on server-based or local databases. If the views are not built, Notes will build them. If the views are already built, Notes will update them, not rebuild them.
If the cutoff date for the database is more recent than the last time/date that the view was updated, the index will be rebuilt. The cutoff date is based on the purge interval, so by default it will be 90 days earlier than the last purge. You can see the cutoff date in the Replication Settings InfoBox in Notes/Domino R4 and R5. Purging is done at one-third the purge interval, and the replication cutoff date will be based on that purge interval. Once the replication cutoff date is reached, you will be prompted with a dialog box containing the following message:
“The Replication Cutoff Date indicates that documents before 02/28/94 01:42:02 PM should be purged from this database. Would you like it to be done now?”
One other instance only occurs for private views. If the user’s privileges have changed since the last time the view was updated, then the private view will be rebuilt.