I have used the DXL Export and import functions of the C Api( 6 Version). Here i exported each of the documents of a Database to an xml file. Then using the Import i imported each .xml to a document in another database.
The problem is that the documents have different Notes IDs and UN Ids when compared between the original and the imported ones. Has any one faced a similar problem, or any ideas / solutions for this problem.
Different note IDs in different databases is normal. Different universal IDs is also normal, unless the databases are replicas and you intend the documents to be replicas. Why is it a problem in your case?
Subject: RE: DXLImport ( compare data base content).
When you import DXL, you create a new document. Notes generates the new document’s universal ID. Your code can then change the universal ID, save this document with the correct universal ID, and remove the document that you imported. The note ID does not matter.
Subject: RE: DXLImport ( compare data base content).
Actually, you can update the existing content during import. On the NotesDXLImporter.DocumentImportOption property, check out DXLIMPORTOPTION_UPDATE_ELSE_CREATE.
Subject: RE: DXLImport ( compare data base content).
Sreenivas starts with “a copy ( say DB2) of database ( DB1) which contains only the design”, and imports the documents. There are no existing documents to update, in this case.
Subject: RE: DXLImport ( compare data base content).
You cannot set the note ID in any way.In C++? Then I have changed my mind. (Apologies, Nathan.) You can use C API functions (or perhaps C++ API) to create an empty document with the universal ID that you want. Then you can use DXL import to update this document with the real data.
I think you cannot set the universal ID and do the DXL import in one step.
Subject: RE: DXLImport ( compare data base content).
Interesting discussion.
We considered making the DXL Importer capable of retaining the DXL-specified UNIDs when creating new notes. I think we even had internal-only versions of the Importer that did just that. After thinking it through, it was an intentional design decision to NOT retain DXL-specified UNIDs when creating new notes. Our rationale went something like this. Generally speaking, when two notes in different dbs have the same UNID, it implies the dbs are replicas and thus that the notes represent the same thing. (There are at least a couple of exceptions to this rule that I know of, but they don’t change the basic point.) When a note is first created in one replica, it gets assigned an UNID, and it is the Replicator that is responsible for creating that note in other replicas, in doing so maintaining the same UNID, and other context (e.g. a revision number) that allow the Replicator to resolve conflicts, etc. When a note is modified in one replica, again the normal mechanism to make the same modifications in the other replicas is the Replicator. If DXL were to get into the business of creating the original notes or updating existing notes in replicas, it would have to be very careful to implement all of the exact same behavior and internal context that the Replicator does, or risk breaking the whole mechanism. But it really isn’t the business of the DXL Importer to do this; the one component of the product that was intended for this task is the Replicator! DXL can certainly be used to create the original of a new note, but from there, it should be the Replicator that pushes it to all the other replicas. The Replicator replicates!
In short, the DXL Importer is not the Replicator, nor should it be.
I have had occasion to force a particular UNID onto a note. Am I remembering right that it is only before the first note update that this is allowed? In any event, that was from the Notes core code. So as it has been pointed out in this thread, it is doable. But it may be risky in terms of possible effects it can have on replication.
Subject: RE: DXLImport ( compare data base content).
[Generally speaking, when two notes in different dbs have the same UNID,
it implies the dbs are replicas and thus that the notes represent the same
thing. (There are at least a couple of exceptions to this rule that I know of,
but they don’t change the basic point.)]
Correct me if I’m wrong, but doesn’t the mail router attempt to preserve the
UNID when adding a note to an NSF? That is, if the UNID of the original
message doesn’t exist in the target NSF, it is maintained.
If not, I’ve no idea how thread maps in mail work.
Subject: RE: DXLImport ( compare data base content).
hi everyone,
thanks for the support. i could complete the DXL import part. it goes like this that we can regenerate a note with( a spec note id and UNID) during its creation. but the DXL Import which imports from the xml file could not import back to the new mail document, but we can use a xml parser to get the id values before importing the document. now we create a new document using these values(ids) and reimport over the existing empty document.
i had to also import the signature of document, but i could not sign the document with the original signature( some other person / server)