Silly Question on DOCIDs

I have Database A and Database B on the same server and file path.

These two databases have 100s of thousands of documents each.  Is there a possibility that atleast one DOC ID of Database A can match exactly with another one in Database B ???

I think I know the answer to this is "NO" all I need is the proof of some kind of documentation.

Thanks!
Arun.
LVL 9
ArunkumarAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

qwaleteeCommented:
Is IS possible!!!!!
0
ArunkumarAuthor Commented:
Come on Qwaletee ... Thats a BIG one.  Can you get me some documentation / proof ?  I dont want you to say that you create a document with unique id same on the two databases.  I want by default if notes creates the doc IDs is there a possibility to get duplicates ???
0
ArunkumarAuthor Commented:
I have a situation here to give explaination to my teammates.  This is just not worth 50 pts.  You WIN MAX always from me !
0
Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

Sjef BosmanGroupware ConsultantCommented:
What do you mean: NoteID or UniversalID?

NoteID is only unique within a db, and cannot be changed.

If you check the documentation on UniversalID, you see that it is a read/write property! I suppose you could set the UniversalID to a value already used in another db, why not?
0
ArunkumarAuthor Commented:
Universal ID.  And i am not playing with these IDs. I want to know if by default this can happen as notes assigns the IDs.
0
CRAKCommented:
Allways BIG scores qwaletee! It just takes a while until you receive them. Arun promised me and out mutual Belgian Bro a BIG reward for our contribution once.... back in Aug. 11! Still waiting!
But good to have you back here Arun. I thought you retired, along with Zvo, JM, Sno etc. when the new EE looks got introduced. Still can't like 'em by the way. Too much baby blue! Too little contrasts, especially on  a LCD display.

About your question....
Let's decide whats used in a doc id. A date time component? A random part? Part of the db replica id (in its turn based on....?). What else?

Theoretically I'd say yes, there is a change. Infinitely small, but still. IF two databases get created on the very same moment in time, and a random generator comes up with the same numbers.... and if documents in those databases get created in the same split second, and the random generator.....
Lets consult our beloved friend Murphy.... if WE can think of it.....

A different approach:
How many different unique numbers can be held in the size of a doc id. Collect all databases around the world, all doc's. What if the total of documents in that amount is 1 larger?
What's the chanche of these "twin-docs" meet and replicate? Who's sick enough to let others lie awake at night and worry over this?
0
ArunkumarAuthor Commented:
Oh man... this is not such a question.  I have a situation here.  And I understand your approach totally.  Just send me some link which explains Yes or No... I will be happy.
0
Sjef BosmanGroupware ConsultantCommented:
Simply put: the length of the UniversalID is finite, therefore the number of unique UniversalID's is finite, so there will be one day two documents in two databases will have the same UniversalID.

Some computations. The size of the UniversalID is 32 positions, with 16 values per position, resulting in 16^32  combinations, which is  3,4028236692093846346337460743177e+38. Assume there are 60 million Lotus Notes users all over the world. If each of them would create a new document every second, it would take them 179838051180100236482842,152583169 years (1,8E23) to use all UniversalID's.

As a mathematician I've got to say that there definitely is a chance that there are two documents in different databases with the same UniversalID. The chance that a double UniversalID will be generated in one year is about 5,5E-24. This probability is definitely NOT ZERO! Undoubtedly, getting struck by lightning is a lot more likely.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ArunkumarAuthor Commented:
DAMN!
    Thats more explainatory for a dumbass like me.  Good one Bozman.  The situation here is I have

Sybase counts - US = 12,927, Canada = 23,544
FAMS Counts -  US = 14015, Canada = 23,547.  

Matches US = 4796.  US In FAMS but not in SYBASE = 9219,
SYBASE not in FAMS 8131.  Matches Canada 7295,

In FAMS but not SYBASE 16252, In SYBASE but not FAMS 16,249

Some junk numbers I have infront of me.  Now I know just plain is there NO possibility that US & CAnada have docIDs that matches in the number of 1000's ?

Whoever agrees to this above statement will get pts.

Thanks guys!
Arun.

0
ArunkumarAuthor Commented:
That was fast grading - Right CRAK ?
0
CRAKCommented:
Now THOSE are numbers that a dumbass doesn't understand.... I can tell!

Based on common sense....
You said thad you have two databases with 100s of thousands of documents. Let's say a million!
And in those 10^6 docs you have 1000 (1 in 1000) matches?

If that would be possible then I know a couple of large companies that run some very important notes databases that should gotten them in some very deep **** by now!

I can't see what the problem with jef's computation could be, but you know 1 million.... thats a "1" with 6 "0"'s, or 10^6.
Jef is talking about a variety of numbers well over 10^38! Half of that number would be: 5 * 10^37 (a "5" with 37 "0"'s, not 10^19!).

A cant offer you any links, but why don't you can generate some scientific proof by setting up a demo... take e.g. 5 PC's. Provide each with a replica of the same database and let all generate 1 million documents. Then let them replicate with each other! If you end up with a documentcount of 5 million, I'll be looking forward to  500 points, grade A! If you'd find even a single document missing, you and I will feel embaressed and seriously need to drown the thought!
If you find that you are about 1000 matches short (1000 in hundreds of thousands, like you wrote), we'd better call IBM fast, or notes developers like you and me WILL run out of jobs soon!
0
CRAKCommented:
Yes Arun, that was fast!
But remember.... "it is possible" doesn't mean that it's likely to happen. It's rather... unlikely! But who am I telling???
0
ArunkumarAuthor Commented:
Well, i was mentioning about 14000 and 23000 docs there is no chance that 1000's of docIDs will be a match !!!
0
qwaleteeCommented:
Oh, well, you got the wrong answer.  You have to understand two things: 1) what a UNID is, and 2) how it is formed.

The API User Guide explains UNIDs.  (Although the title misnames them Note IDs.)  The UNID has two parts, the UNID.File and UNID.Note.  Each is a 16-digit hex number.  Starting with Notes 3.0, it is a random number.  UNID.Note is the time-date that the document was created.

So, by pure happenstance, it is unlikely that two documents would share a UNID.  They would have to coincidentally be created at the same time (or its equivalent, given clock inaccuracies).  And it would have a 1/2^128 chance even given taht possibility.  On the same server, it is even less likely, because the busy time the server has when creating the note typically precludes another document getting created in the same clock tick (not to be confused with CPU clock cycle), and teh random number generation routine more or less precludes the server from using the same random number twice in a row.

That saud, all the above is a lie.  Smetimes.  Aside from the fact that the UNID can be manipulated (an accident Bob Balaban made, I think), there are situations where Notes contrives to re-use a UNID.  When documents are moved from one database to another, Notes OMSTIMES attempts to keep the UNID of the original document.  It does this, for example, in certain versions, on cut and paste, so it does not have to recalculate $Ref values.  The router does this for mail thread tracking.  So, i all likelihood, if you have two mail users on a single server who communicate with each other, they have common UNIDs in their mail databases, so the likelihood is actually quite HIGH that Arun's situation will occur, at least for mail.

0
madheeswarCommented:
This is a good discussion. I missed it.

So, Qwaletee, u mean that their is likely to have same UNID for mail databases between two users.

And it is impossible to have same UNID for applications? Exceptional is copy/cut and paste(In this case may have same?).

Am I correct?
0
CRAKCommented:
I knew of the mail thing and the cut/paste. Good point in mentioning that, but this isn't about mail, and after cutting a document from a database, and pasting it into another, the docid still resides in one database only, right (I disregard db-replicas that might replicate the original document back into the original database here!).
(Is there a link to how to change doc id's, Qwaletee?)

Arun, what raised this discussion? You mentioned Sybase.... is there a database connection? A conversion perhaps? And what's FAMS?
0
madheeswarCommented:
I won't think that DOCID can be changed.

But once u cut and paste any document, DOCID won't change.
For Copy and paste, DOCID will change.

And replicating scenario I don't have any idea. Try to enlighten me on this.

-Thanks.
0
CRAKCommented:
After cutting, a deletion stub remains. This enables notes to replicate the deletions.
Imagine that a local replica holds cut document, but doesn't replicate for a while. After (default) 30 days, the deletionstub itself is removed.
Once that's done, you can replicate the isolated replica again. The (originally cut) document is now again replicated back INTO the database (since notes doesn't remember that the doc was deleted).
Result: two databases sharing a doc id!
0
ArunkumarAuthor Commented:
FAMS is Notes Application.  We have two databases in Notes. One for US and one for Canada.

These two databases send documents separately to one sybase table.  After 4-5 years we started thinking of cleaning up redundant/unused/bad data from both notes and sybase.

We are using DocID as the Key in sybase and are trying to generate a report.  During this process there arose a question from the sybase person can FAMS US and FAMS Canada generate same DocID ?  We have way too many non matching docIDs than matching ones.  In thousands.  So, we wanted to make sure that out of 14000 and 23000 docs in notes will there be an overlapping docs in thousands that share the same DocID.  Now check the numbers I have given before.  It will make a little sense to understand but utter nonsense in regards to the data we have...

Hmmm...
0
Sjef BosmanGroupware ConsultantCommented:
If you have 1000's of matching DocID's, couldn't it be that you refer to the NoteID, and not the UniversalID??
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Lotus IBM

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.