Short Description: Forces a new UNID to be created for a document after being copied to the destination database (via LotusScript CopyToDatabase)
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).
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:
Prior to this fix, when using the LotusScript CopyToDatabase method (of the NotesDocument class), a new UNID was not generated for a document each time it was copied to a target database. See technote for more information.
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.
CopyToDatabase_New_UNID=0 / 1
There is no kown UI setting for this notes.ini variable. But you can specify this setting in the notes.ini settings tab of the configuration settings document.