Hi FriendsAs Name suggest Universal ID is unique but it is unique to what ? i mean if there are two different database on two different servers then is there any chance to have same Universal ID on these two database
Thanks
Subject: Clear picture of Universal ID
This is really basic stuff and the product documentation covers it pretty well.
The universal id or document unique id is unique for a document across all databases. Two documents will have the same universal id only, if the databases are replicas of each other and those documents are meant to be synchronized.
Subject: RE: Clear picture of Universal ID
Actually, that is not true.
While the chances are small (about one in 2^64), there is nothing that prevents two documents in different databases (i.e.: not replicas) to have the same document unique ID.
The Universal ID of a document is basically an 8 byte random number concatenated with an 8 byte representation of the creation date/time of the document.
So the universal ID is unique for a document across all replicas of a database. There is no guarantee that it is unique across different databases, which can be either by coincidence (read up on the birthday paradox) or by design (the unid can be programmatically set).
cheers,
Bram
Subject: RE: Clear picture of Universal ID
This is inaccurate. A universal id is 16 bytes, eight of which represent the a unique random number generated at the time the document is generated and eight of which represent the document’s exact creation moment. So, you would not only need two documents created at the same instant, which is not all that uncommon, but for the eight byte random number to be the same as well. Very, very unlikely. Not that it is impossible, just not worth worrying about.
Subject: RE: Clear picture of Universal ID
Hi Ben,
I thought that you of all people in these forums would have a good grasp of the low level Notes API (including the various ID structures).
In the C API guide there is a document called “Anatomy of a Note ID” that will go into detail in all the IDs.
You are thinking of the OID, which includes the replica ID of the database combined with the note ID of the document.
The universal ID is just a random number plus the TIMEDATE representation of the creation date of the document. This is also where the @Created value comes from.
typedef struct {
DBID File; /* Unique (random) number */
/* (Even though this field is called "File," */
/* it doesn't have anything to do with the file!) */
TIMEDATE Note; /* Original Note Creation time/date */
} UNIVERSALNOTEID;
#define UNID UNIVERSALNOTEID
In the universal ID there is nothing linked to the database where the note was created as it would (obviously?) be redundant.
cheers,
Bram
Subject: RE: Clear picture of Universal ID
You caught me. Actually, there used to be a connection, but there isn’t anymore, so I wrote it, remembered that I was wrong about that and revised my post. You obviously caught the post before the revision went out.
Back when I was learning such things, in Notes 3, instructors commonly taught and the API documented in some places that the first part of the UNID was the database id. You will notice that even now, the documentation shows this as the definition of UNIVERSALID:
typedef struct UNIVERSALNOTEID_tag {
DBID File;
TIMEDATE Note;
} UNIVERSALNOTEID;
which reflects its old usage. As they explain in the C API:
The “File” member of the UNID contains a number derived in different ways depending on the release of Domino or Notes. Pre- 2.1 versions of Notes set the “File” member to the creation timedate of the NSF file in which the note is created. Notes 2.1 sets the “File” member to a user-unique identifier, derived in part from information in the ID of the user creating the note, and in part from the database where the note is created. Notes 3.0 sets the “File” member to a random number generated at the time the note is created.
The problem was that computers were getting faster quickly, and so in Notes 2.1, they changed this to a user unique number, but by R3, even that wasn’t good enough because a single user could run an agent that would create two documents close enough together, so they moved to a unique random number. Unfortunately, it took the documentation and “general knowledge” a while to catch up, so unsuspecting newbies such as I was back then learned the wrong meaning for this, reinforced by the naming of the elements. By R4, I was correcting people about this, but here by ND8, I simply forgot and wrote what I used to know. After a bit of reflection, I remembered that this was incorrect, but I am not surprised (and even a little pleased) that somebody would cath me in that. Steve Lister, for example, will be pleased to see that I still commit the occasional faux pas .
Subject: RE: Clear picture of Universal ID
After re-reading this posting, I got a bit worried that I had misread your answer so thanks for letting me know that I won’t have to worry about having early-onset Alzheimer’s (yet ;-).
I started with Notes on R4, so obviously I’ve never known that UNIDs behaved differentely in earlier versions of Notes. Goes to show that you can learn something new every single day.
And hey, it’s always nice when you can score one against someone who seems to have been around forever and knows nearly everything there is to know about notes 
cheers,
Bram
Subject: RE: Clear picture of Universal ID
You are right, I should have been more strict on this issue. For practical purposes, you can usually assume DocUnIDs to be unique across all databases you will access, but this does not have to be the case. And after all, uniqueness doesn’t really matter, if databases are not replicas.
I’d like to add, that while you can change the universal id programmatically, you can not do that directly using LotusScript or Java, but just through the C (C++??) API. Changing the universal id of a document is LS or Java will create a new document (you could still delete the original one, of course).