DocumentCollection vs Array of Documents

Ok, not a real comparison, but some curious behavior on the part of a DocumentCollection has reminded me why I abandoned manually creating DocumentCollections in favor of a good, old fashioned arrays. Not to say that the documentcollection does not have its uses, but I cannot figure out why it would not work for me in this particular instance.


The premise is easy enough. An application has a requirement where hundreds of documents can be changed in batch mode, but if there is an error anywhere in the change process, the process needs to back-out the changes. My take on this requirement is to gather the documents into a document collection and if there are no errors, the last step will be to loop through the DocumentCollection and save each one. I figured that the “AddDocument” method of the DocumentCollection object would be alot easier than redimming the array every time a document is added.

The DocumentCollection seemed to populate fine and the loop that does the saving worked just fine, the only problem is that only one document kept the changes. All the rest were untouched. The document that saved was always the oldest document in the collection.

Well, I have not figured out why this happens, but I think it stems from this AddDcoument entry in the Help file:

For sorted collections, the document will be appended. For unsorted collections, the document will be inserted using an internal algorithm.

I have no idea how the “Internal Algorithm” works, but I think that is what prevents the DocumentCollection.AddDocument from working like I had hoped. Since I SET my documentcollection with a “fake” View.GetAllDocumentsByKey, my collection would fall into the Un-sorted category. Reverting to an array of documents, and redimming every time I add a new document, worked like a charm.

Any ideas on this?

3 Responses to “DocumentCollection vs Array of Documents”

  1. Dan Sickles Says:

    I use lists. I only use arrays where a list won’t work (which is rare). Something like this:

    dim docs list as Notesdocument

    set doc = view.getfirsdocument
    do while not doc is nothing
    ‘update doc here
    set docs(doc.noteid) = doc
    set doc = view.getnextdocument(doc)
    loop

    ‘if all is well
    forall d in docs
    d.save
    end forall

  2. Administrator Says:

    Very true Dan. I guess I never think of using lists if I do not have to reference individual list members with a key. At least I would not have to constantly REDIM.

  3. Jerry Carter Says:

    Hey Jeff,

    If you’re processing your collection with a loop, which I am guesing you are, you are probably using a temporary NotesDocument object, ala DocumentCollection.getNth or .getNext, etc. If I further understand what you were trying to do, not saving till you’d touched all docs, you were essentially using a locally scoped variable (the temporary nodetDocument object) that kept getting overwritten with each iteration. The changes are not committed to the objects till you save, so you looped through, making changes but not committing them, and then lost each change up till the last because the temp doc obj was reassigned next time through the loop.

    Make sense? It sounds like that is what happened. A simple change wold be to run the loop once without saving in ‘validate’ mode, then repeat the entire loop with save ‘enabled’ in ‘write’ mode.

Leave a Reply