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.
Custom types in Documentum solutions benefit from inheritance in a type hierarchy. It is quite common to have a base type for a particular application/solution and the other custom types are derived from it. A common base type also facilitates querying all the related custom types since the query can use the base type in the FROM clause rather than enumerating all the subtypes. For example, a base type
financial_doc could be used where the concrete document types are
A side effect of this choice is that the base type also starts showing up on the Import screen (and probably some others where it may not be desirable). The base type may be akin to an abstract class and we might not want users to use this type when importing documents or creating objects. It might also be difficult to hide this type by simple configuration. Maybe we don’t want this type to show up anywhere on the UI other than in a few specific places. Is there a way to hide the type on the UI while still keeping it available for use?
This requirement can be accomplished by using the data dictionary attribute (easily via Documentum Application Builder) – lifecycle (
dmi_dd_common_info.life_cycle). This attribute can have the following values 1=current 2=future 3=obsolete Like other data dictionary items this is just a hint for client applications. However, EMC products such as Webtop respect this attribute. When this attribute is set to anything other than 1, the type is available for all purposes, it is just not shown on the UI. The same approach can be taken for hiding an attribute.
It is quite likely that we do want the type to show up on the search screen since it enables us to search across all of its subtypes. This will require a customization that “hard codes” the type to be displayed. Often, this can be accomplished by modifying the appropriate JSP.