Invalid UniversalID when document has been copied

Question

I have a strange problem: I want to access documents in a different database (same server). My approach is very close to this one discussed here: http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllFlatWeb/517ef6249d5b9fa6852575cc00503786?OpenDocument

I have only 3 docs in the source database. 2 are created directly, one is copied from another database (these are just test document). We have a generic view that lists thos entries from a view, calcs the links in a form like this:

http://localhost/database.nsf/xpMBK.xsp?action=openDocument&db=dominotest%2Ftest%2Fulcbs%21%21projects%2FFKIE%2FEinsMuB.nsf&view=AMBKEinsAll&documentId=781F14A98A699548C1257C3200316BAC

As you can see we are using an Xpage in the current database and place parameters that point the Xpage to open the document to the source database (notation is server!!database here), a view (this is the one to which I want to return) and finally the unid of the source document.

Now the strange one: I cannot open the copied document, receiving the

NotesException: Invalid universal id
lotus.domino.local.Database.getDocumentByUNID(Unknown Source)

error. Even better: if I copy a document that works within the same database (the current one) this document can also not opened anymore! What's this and can you give me a hint to solve this?

Thanks in advance!

Answer 1

If, by "copied", you mean either manually copied and pasted into the target database or programmatically duplicated via copyToDatabase(), the new copy of the document will be assigned a new UNID; it is not guaranteed to have the same UNID as the original did (and, in my experience, it's rare that it preserves the original). If you're duplicating the document programmatically, be sure to check its new UNID afterward and use that ID in your URL calculation instead.

Answer 2

I've had a problem very similar to this in the past, and the answer turned out to be that I wasn't opening the NSF file that I thought I was opening. I was using NotesDatabase.OpenByReplicaID, and there were two replicas of the database on the server, with different sets of documents. In that situation, Notes gets to pick one of the two replicas -- you have no control over it. The replica that was actually opening contained some of documents corresponding the the UNIDs that I was trying to access, but some of them really were not there and therefore the getDocumentByUNID() method was correct in throwing the "Invalid universal id" error. This was really, really hard to debug.

After I figured it out and removed the second replica from my server, the first thing I did (after testing and confirming the problem went away) was to write an agent that scans a server for duplicate replica IDs.

Answer 3

The UNID:S in a Domino database when it's copied to the database thru copyToDatabase is done like this. One part of the UNID comes from the database one part is document unique. So if you copy a document from one database to another the document could get the same unid each time. If the unique combination doesn't have a valid document with that combination in the database, the document will get the same UNID everytime. In other cases the document will get a new Id.

More information can be found here UNID and copytodatabase

Answer 4

Thank you guys for your ideas! But I was completely wrong #facepalm The problem was: a colleague coded a bean to access the other database and I didn't noticed that the config document pointed to a replica on another server, so when I copied the document within my database on my local server it was fairly clear that the xpage could not find the copied one - as it resided on the other machine. Thank you anyway :)