3

I have 2 databases : let say dbA and dbB. Actually, dbB is a ''child'' database of dbA, because the forms/views/frameset/etc that it contains they all are also in dbA.

I want now, to copy from a view ( let say vwA ) from dbA some 8K docs to the same view ( vwA ) from dbB. THese 8k contains both parent and child docs, which in dbA are listing OK, with @Text(@UniqueDocumentID). I just made a test, copy one parent doc and its response, and pasted in the 2nd database, but unfortunately the connection between the 2 docs isn't made... I guess the UNID had changed...

Is there any solutions? Thanks for your time.

Knut Herrmann
  • 30,880
  • 4
  • 31
  • 67
Florin M.
  • 2,159
  • 4
  • 39
  • 97
  • Two remarks: 1) try to avoid using UNIDs for referencing purposes, and 2) investigate whether you can use standard Lotus archiving (which retains the UNID afaik) – D.Bugger Jun 24 '13 at 08:13

3 Answers3

10

Yes, copying a document to another database always creates a new UniversalIDs for document in target database.

To avoid this, your LotusScript should work like this:

  • create new document in target database
  • CopyAllItems from source document to target document
  • set same UniversalID to target document targetDoc.UniversalID = sourceDoc.UniversalID
  • save the target document

This way the target document has the same UniversalID like the source document and links between document should work in target database too.

This is an example for an agent working on selected documents:

Dim session As New NotesSession
Dim dbSource As NotesDatabase
Dim dbTarget As NotesDatabase
Dim col As NotesDocumentCollection
Dim docSource As NotesDocument
Dim docTarget As NotesDocument

Set dbSource = session.Currentdatabase
Set dbTarget = session.Getdatabase(dbSource.Server, "YourTargetDatabase.nsf", false)
Set col = dbSource.Unprocesseddocuments
Set docSource = col.Getfirstdocument()
While Not docSource Is Nothing
    Set docTarget = dbTarget.Createdocument()
    Call docSource.Copyallitems(docTarget, true)
    docTarget.UniversalID = docSource.UniversalID
    Call docTarget.save(True, False)
    Set docSource = col.Getnextdocument(docSource)
Wend
Knut Herrmann
  • 30,880
  • 4
  • 31
  • 67
  • Thank you, dear Knut. Unfortunately, I'm a newbie in Lotus programming, and I will need a help for the code, I guess – Florin M. Jun 21 '13 at 07:20
  • Thanks, I will try it! I have a question: There are two Set dbSource: Set dbSource = session.Currentdatabase Set dbSource = session.Getdatabase(dbSource.Server, "YourTargetDatabase.nsf", false). Is this OK? Thank you Knut! – Florin M. Jun 21 '13 at 08:06
  • And the agent is running on the Source Database? Thanks. The 2 databases are on different servers – Florin M. Jun 21 '13 at 08:18
  • Yes, this agent should be defined in and runs on source database. You can replace the target server. Write `"YourTargetServer"` instead of `dbSource.Server` – Knut Herrmann Jun 21 '13 at 08:49
  • and the 2nd Set dbSource shouldn't be Set dbTarget ? – Florin M. Jun 21 '13 at 08:53
  • Sorry, you're right, changed code to `Set dbTarget = session.Getdatabase(...` – Knut Herrmann Jun 21 '13 at 08:53
  • I highly recommend NOT to change the UniversalID of the copied documents... When I started at my current workplace, they had an application that did exactly that when documents were archived. What happend was that later the documents were moved back into production (un-archived) and promptly deleted because of the replication stubs that existed in production. So I would never do it that way. – Karl-Henry Martinsson Jul 01 '13 at 14:36
  • What I would do is as follows: 1) copy the main document to the archive database (database B) 2) get the UNID of the new document 3) copy the response documents to archive database 4) Use the MakeResponse method to make the documents responses to the main document That should be it. If you have any hard-coded references to the parent in the response documents, using a field, you can update it at item 5 in the list above. Or rewrite it to use $REF to get the parent (in formula). – Karl-Henry Martinsson Jul 01 '13 at 14:41
0

Or, you could let replication handle this for you by setting a replication formula, assuming that dbA and dbB are replicas.

sjcaged
  • 649
  • 6
  • 25
-2

I think the easiest way is creating a script and copiing the documents using the CopyToDatabase method of NotesDocument class. The CopyToDatabase method retains the UniversalID of documents (for perfomance reasons). This is true at least for Versions up to R7.

More information can be found here: IBM Technote: Documents copied using CopyToDatabase method reuse same UNID

A sample Script (copied and modified from Knut) would be: 

Dim session As New NotesSession
Dim dbSource As NotesDatabase
Dim dbTarget As NotesDatabase
Dim col As NotesDocumentCollection
Dim docSource As NotesDocument
Dim docTarget As NotesDocument

Set dbSource = session.Currentdatabase
Set dbTarget = session.Getdatabase(dbSource.Server, "YourTargetDatabase.nsf", false)
Set col = dbSource.Unprocesseddocuments
Set docSource = col.Getfirstdocument()
While Not docSource Is Nothing
    Set docTarget = docSource.Copytodatabase(dbTarget)
    Set docSource = col.Getnextdocument(docSource)
Wend
Michael Ruhnau
  • 1,399
  • 1
  • 7
  • 15
  • Thank you, Michael! This is also an example for an agent working on selected documents from a view? – Florin M. Jun 21 '13 at 09:24
  • Yes, the agent uses the "UnprocessedDocuments" property to get the DocumentCollection. This processes documents selected in a view. You could change this to process all documents in a view (or anything like this) if required. – Michael Ruhnau Jun 21 '13 at 09:28
  • Thanks! I will give it a try and announce you later. – Florin M. Jun 21 '13 at 09:29
  • I did run the agent on the selected documents, they all have been copied. But the UNID of the parent docs have changed , so the relation between the parent and response docs isn't made – Florin M. Jun 21 '13 at 09:39
  • 1
    The interpretation of the quoted IBM article is wrong. Copytodatabase does NOT keep the unit. It just keeps the unid for the same documement copied multiple times (if deleted)... Read carefully... CopyToDatabase is NOT a solution for this problem – Tode Jun 21 '13 at 11:30