When do documents change their UniqueID?
by jcf. Average Reading Time: less than a minute.
I’ve been chasing a bug for a couple of hours now…. “Entry not found in index” seems to be a classical @DbLookup that fails… Well, wading through the form, removing blocks of fields, testing again, and again and again and never getting rid of the error on one specific document (but on other everything’s fine). The Domino developers know the drill – it’s frustrating.
The I looked at the URL – I was opening a doc by it’s UNID. I searched for that doc in the database but couldn’t find it by that UNID. So I looked at the code that creates the URL. It takes the UNID from a computed field that contains @Text(@DocumentUniqueID).
And guess what – the UNID had changed between when the document was saved the last time and reopened.
The big question: Why does the UNID of a document change, even though it hasn’t been updated through the Notes client? (because then the computed field would have the correct UNID)
I suspect TeamStudios Configurator (The global search and replace tool for Notes). Anybody know more about that?
Is the document created via a web app? If so, are you preserving the computed field value by sending it on a round-trip to the browser during the ?OpenForm ?CreateDocument cycle? If so, the actual UNID will not match the value that you saved, because the UNID value created during the OpenForm operation is thrown away and a new UNID value is created during the CreateDocument operation. There was discussion of a related issue recently in Rocky’s blog, here http://www.lotusgeek.com/SapphireOak/LotusGeekBlog.nsf/plinks/ROLR-5PXKBP. There are several ways you might be causing the round-trip to happen. The database property that I mention in my response in the above-linked thread could be doing it to you without you realizing it.
-rich