The best way to manage this involves a two-part procedure. The views should initially be private on first use. That way, they can be updated by updating the database design. However, to get the new design, users need to run code to delete their version of the view, and then recreate the view by opening the private view on first use of the new design.
Explaining to users how to refresh the design of Private Views and Folders is not always easy. To automate this, there are numerous solutions for deleting the Private View and Folders but when r6 was released a regression bug was introduced. My tip, Deleting 'Private on first use' views/folders, gets around it. The bug is addressed in SPR# DBLK5E6L8V for 6.0.4/6.5.1 and SPR# TGOO5JVEGC 6.0.4/6.5.2.
We too had this problem with private views in various databases in our company. Our solution, which always works fine, is as follows:
- Private views must be created as real private views -- i.e., view type must be 'private.'
- Put the following code in the QueryClose event in the database script:
Dim session As New NotesSession Dim db As NotesDatabase Dim view As NotesView Dim docView As NotesDocument Dim itmFlags As NotesItem Set db = session.CurrentDatabase Forall v In db.Views Set view = v Set docView = db. GetDocumentByUNID( view.UniversalID ) If Not docView Is Nothing Then Set itmFlags = docView.GetFirstItem( "$Flags" ) If Instr( itmFlags.Values ( 0 ), "V" ) Then Call view.Remove End If End If End Forall
This way all private views are deleted each time the user leaves the database. They are recreated when used.
This way you never have to worry about destributing design changes and nobody has to do or think of anything anymore.
Do you have comments on this Ask the Expert question and response? Let us know.
This was first published in June 2004