Documents copied using CopyToDatabase method reuse same UNID

Problem

In Lotus Domino Designer®, when using the LotusScript CopyToDatabase method (of the NotesDocument class), a new UNID is not generated for a document each time it is copied to a target database. If a copied document is deleted from the target database and then copied from the source a second time, the resulting document's UNID will match the UNID of the first document copied (within the target database).

Example:
1. A document in a source database has the following UNID (spaces added to ease reading):
86A84028 1DE69507 85256A9D 005635D0

2. The copy generated by CopyToDatabase has the following UNID (the last 16 characters match the original document's UNID):
E7271252 50D66FE4 85256A9D 005635D0

3. If the above copy is deleted and copied again, the UNID is a duplicate of #2 above):
E7271252 50D66FE4 85256A9D 005635D0

This can present an issue for some applications in which an agent copies documents, documents are being deleted, and replication is occurring, with the result being save/replication conflicts instead of actual documents.

NOTE: If the documents are manually copied from the source and pasted into the target database, then new UNIDs are always generated. If a document is copied twice using the CopyToDatabase method without deleting the first one, the second copy will always have a new and unique UNID.

Resolving the problem

This issue was reported to Quality Engineering as SPR# ASHW4X9P8R and was fixed in Lotus Notes®/Domino 6.0.4, 6.5.2, 7.0, and later releases, by the addition of an optional notes.ini parameter. The following notes.ini parameter forces a new UNID to be created for a document after being copied to the destination database:

CopyToDatabase_New_UNID=1

Workaround for versions prior to 6.5.2 and 6.0.4:
If the CopyToDatabase method is used to copy the same document (to the same database) more than once, the additional document copies will be given entirely unique UNIDs which will not repeat if the process itself is repeated. This fact can be used to work around this issue by calling the method twice and then removing the first document copied. The only possible detriment to the example below is the additional deletion stubs that are created. This method is still recommended as it is very straightforward and reliable.

Set tempdoc=doc.copytodatabase(db)
Set newdoc=doc.copytodatabase(db)
Call tempdoc.remove(True)

Supporting information
The design decision for this behavior may be relative to the following: At times, performance issues have been observed when ID tables in a database become fragmented. Retaining UNID values was a design decision to conserve UNIDs for greater performance. Deleting documents and copying them back in is easier to do when writing an application but yields a greater fragmentation rate in a database, due to deletions and adds.

Steps to reproduce

1. Create two databases: DB1 and DB2.

2. In both databases, create a view called UNID and place Steps a-d below into both views.

a) Place this formula in the first column: @Text(@DocumentUniqueID).
b) Categorize the column in ascending order.
c) Create a view-level action button named "Copy docs to DB2".
d) Paste the following code in the button (or similar LotusScript code):

Dim s As New NotesSession
Dim db1 As NotesDatabase
Set db1 = s.CurrentDatabase
Dim view1 As NotesView
Set view1 = db1.GetView("UNID")
view1.Refresh
Dim db2 As New NotesDatabase("servername","database_2.nsf")
Dim doc As NotesDocument
Set doc = view1.GetFirstDocument
While Not (doc Is Nothing)
Call doc.CopyToDatabase(db2)
Set doc = view1.GetNextDocument(doc)
Wend

3. Create a new form in DB1 only and add any simple fields you want. Save and close.

4. Create one or more new documents using this form.

5. In the UNID view of DB1, click the button to copy these new documents to DB2.

6. Open DB2 and look at the UNIDs for the documents. Copy the number down or make a screen shot of them.

7. Delete the documents from DB2.

8. Go back to DB1 and click the button again to copy the documents to DB2.

9. Open DB2 again and note the UNIDs of the documents. They are the identical set of UNIDs of the docs you deleted.

10. Delete the document(s) from DB2 and use the button to copy the document(s) again. Every time you copy over the document(s), the UNIDs in DB2 will always be the same UNIDs. If you copy the documents a second time without deleting them, a new set of UNIDs is created.