Introduction
The View.AutoUpdate property has been around for a long time. It provides a level of control by the application over how it should react to updates within Notes/Domino views. It can be extremely helpful in applications that have busy views. It also has the ability to be a significant drag on performance in some pathological cases. Recently, certain details on it have evolved in a benign way. It will continue to evolve in the near future.

AutoUpdate property
When the backend is asked to instantiate a View object, the latest updates are retrieved so that they are available when the View collection is iterated. When the View.AutoUpdate is set to "true", the backend is obliged to listen to the View for notifications indicating an update has taken place. If the view is busy, it may have updates many times during the execution of a single backend method, causing all new updates to be requested multiple times. This can be a significant performance problem on a real time application. If the application itself is making updates to the View, the behavior may degrade seriously. This can be less important to an application running under the agent manager, where it runs unattended and during periods of low usage.

If View.AutoUpdate is set to "false," the backend will generally not listen for updates. The View is updated on creation, but updates made within method execution are ignored.

View designs to safely use AutoUpdate = false
Since all Notes/Domino views are dynamic, they can be in constant flux, depending on the application. In the general case, if AutoUpdate is false, incorrect results could be obtained from some methods. For example, the wrong documents may be returned in a result set or newly added documents may be missing.

There are many views where updates are benign by nature and can be safely ignored, but if AutoUpdate is true, performance would be slowed. In these views, the property should be set false to gain the performance advantage.

Note that the default setting for AutoUpdate is true, to guarantee accurate results under all conditions.

To be a safe yet fast application that makes use of AutoUpdate=false, views should be designed so that updates can be safely ignored. In other words, there should be an implicit guarantee that any updates made during an application will not change the order of the view collection or what appears in the view collection. The best way to do this is to query specially qualified views, in which the view design is sorted on date ascending so that all updates fall at the end of the View. Note that if a view exists in a non-compliant form, a special programmatic view could be created having the desired characteristics for some applications. Alternatively, updates that change the order and set of documents that occur in a view could be queued and delayed until an off time, such as overnight..

When AutoUpdate is important
Recently, some View methods have been upgraded to use new specially designed core services. Under specific situations, the AutoUpdate flag may be set to true, and not adversely affect performance., Some confusion among the users has resulted. To clarify, a list of methods and conditions where the AutoUpdate property essentially has no meaning follows:

Method	Database access	View.AutoUpdate affects Performance?
View.getDocumentByKey	local (resides on machine running program)	no
View.getDocumentByKey	remote (resides on another machine, across network)	yes
View.getAllDocumentsByKey	local (resides on machine running program)	no
View.getAllDocumentsByKey	remote (resides on another machine, across network)	yes

For all other methods which produce or iterate a View collection, whether DocumentCollections or ViewEntryCollection, it may be assumed that the View.AutoUpdate property does affect performance.


Futures
Going forward, the above chart will evolve. More methods and more conditions will become independent of the AutoUpdate property. These changes will always result in better performance for the application. Behavior will not be affected.