Why To Be Careful When Copying Views

Home » Why To Be Careful When Copying Views

We’ve all done it. We want to create a new view, but we don’t want to create it from scratch. We have one similar. So we copy and paste and modify it. It’s quick, it’s easy, it works.

Most of the time.

Sometimes it comes back to bite you because of seemingly innocent column settings. I needed a view to move data to an archive database. For better performance I decided against a NotesDocumentCollection in preference for a NotesViewNavigator and NotesViewEntries. So my code was looping through the entries, copying them to the archive and deleting them from the source database – of course, remembering to get the next entry before processing each entry. (There are pros and cons to removing the entries as each is copied vs removing all entries at the end.)

What I had not noticed was that some columns had “Show multiple values as separate entries” ticked.

The outcome: periodically the agent would error but with no consistency over how many documents had been processed. As I realised, it was because the next entry was the same NotesDocument as the current entry and had already been copied to the archive database and deleted.

Lesson learned.

1 thought on “Why To Be Careful When Copying Views”

  1. When using a NotesViewNavigator and NotesViewEntries to move data to an archive database, what are some important considerations and potential challenges to keep in mind, especially when dealing with column settings? Could you explain the pros and cons of removing the entries as each is copied versus removing all entries at the end?

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top