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.
Documentum installation owner user id is used for installing Documentum Content Server. On Windows, the installation sets up services for each repository (docbase), connection broker (docbroker), and Java method server. If you run into issues related to the installation owner id (typically authentication related), there are two aspects that can be checked:
Each repository service has an associated command-line which specifies the installation owner as an argument. This command-line is visible on service properties when inspected through Windows services. You can edit the command-line through Documentum Server Manager utility. Select the relevant repository and click on the Edit Service button.
Note that this argument overrides the install owner specified in server.ini in case there is a conflict between the two.
All the windows services use logon credentials and the Documentum services mentioned above use the installation owner credentials. These can be edited through the standard Windows service properties dialog.
Issues related to the installation owner may arise when it is a domain user (as opposed to a local user) and/or when multiple content servers are being used. Another aspect to remember is that while Windows treats the user id as case-insensitive Documentum treats it as case-sensitive. Repository configuration also creates a user in the repository for the installation owner, using the exact case as entered during the installation process (at login time prior to installation).