Recently, I had to script DAR installation for a bunch of DAR files as a part of an upgrade effort. The target repository version was 6.7 SP1. During DAR installation, I ran into the DM_OBJ_MGR_E_VERSION_MISMATCH error quite frequently. The message for this error looks like:

MSG: [DM_OBJ_MGR_E_VERSION_MISMATCH]error: “save of object xxxxxxx of type yyyyyy failed because of version mismatch: old version was zzz”;

When this error occurred, I got the same error even with dardeployer. I tried forcing full data dictionary publish and cache cleanup, but the error won’t go away. Eventually, I found a fruitful way to make the error go away consistently.

Each time the error occurred, bouncing the content server service for the repository got rid of the error.

Composer Project Install History (D6.5)

Recently, I got curious about the mapping for Documentum project artifacts to repository objects. While this post shed some light on the subject, I wanted to see it for myself. Another driver was that I had not done a DAR install, rather I had installed the project from Composer. Here is what I found.

There is a dmc_dar object, named the same as the Composer project. It is versioned with each repeated install of the same project to the repository. The content type of the object shows up as jar but in reality it is an XML file. When I tried to open it as an archive it indicated that the file was corrupt. I was able to view the XML by opening it in an editor. It showed the resolution map for artifacts to object IDs.

One thing I suspect based on the referenced post above is that if I installed a DAR then the DAR file will show up as the jar content (correctly). I will have to explicitly get to page 1 of the content to view the XML.