Spanky's Place

I ran into an interesting issue yesterday after having pushed some design changes to an existing production application database.

It seems that some of the users of the application, when opening some of the views, were seeing nothing but replication conflicts, instead of normal documents. Every single entry in the view appeared as a Replication Save Conflict. The offending views differed from user to user, and the Replication Conflicts View only contained two documents. The only thing that the users who were experiencing these symptoms had in common were:

1. They were all accessing the database using a Notes Client (web users were unaffected)
2. Their Notes Client versions were between 6.0 and 6.5.5 (primarily 6.5.3)

My first instinct was that the issue probably had to do with the version of the Notes Client being used (and in a small way I was correct); however in my haste to solve the problem (this is a really important production application) I failed to notice the most important clue: the offending views differed from user to user. I thought that perhaps the offending views contained some design elements (shared columns) or @Formula in either the selections, column formulas, or view actions that were somehow incompatible with Notes Client versions prior to 6.5.5. Our corporate standard version is R7.0.1, and the changes had been developed, tested, and UAT using this version.

After chasing several dead-ends, and doing a bunch of searching on the web, I realized the culprit was not incompatible design elements, but in fact the client side cache. The technote that helped me figure this out (while not explicitly mentioning the symptoms our users were experiencing) can be found here. It seems that the Notes Client 6 versions (up until 6.5.5) will sometimes refuse to release a cached design element (in this case the view design note), even when the design of a database has been updated. Restarting the Notes client (and even restarting the machine) does not solve the issue.