[DM_OBJ_MGR_E_VERSION_MISMATCH]

[DM_OBJ_MGR_E_VERSION_MISMATCH] , We are updating one business object in stateless process using set process data mapping activity, we are getting this following error, please help asap.

~~Error:~~
save object 0b12d68708049be0c of type (object Name) failed because of version mismatch: older version was 10" ERRORCODE: 100 NEXT: null

Comments

  • Hi Keishna,

    Run stateless process in debug mode from Designer to get more details on error.

  • Hi,

    In debug mode we are not facing any issue

  • Hi @Krishnasami,

    Minor bookkeeping: I think you posted this in the wrong forum, not a lot of people visit General. Please let me know which Documentum product this is, and I'll move it to the relevant forum.

    Martin van Rappard
    Technical Support Engineer III
    OpenText

  • Hi ,
    Documentum XCP 2.3

  • How are you getting object to update (ie DQL query)? Posting a screenshot of your SP would help.

  • It seems like you are trying to update a folder (0b12d68708049be0c). It it possible that the same folder gets updated by several instances of the same stateless process? If yes, then you should probably change the design of your process to avoid that.

  • Alternatively, instead of using Process Data Mapper to update attributes, you can also run update DQL. Using DQL to update object minimize version mismatch issues.

  • Not sure this is such a good idea Johnny! Version mismatch errors happen for a reason: they prevent two users from updating the same object at the same time, the result being that one update overwrites the changes from the other one, potentially getting the object in an inconsistent state (from a business point of view).

  • Thank you All. We changed design of stateless process . we used write to repository activity and updated the folder object.
    It is working fine.

  • Hicham,

    I totally agree with your statement; version mismatch happens when two people fetch an object locally, update the object attributes, and then try to commit the changes back to the server. The version mismatch happens when the user who is updating it, didn't fetch object last. Fetching it again and then making the changes will alleviate the issue. DQL UPDATE gets around this issue by not fetching the object and just updating the object via database transaction. If another user fetched the object, and he/she will still get the version mismatch. However, the SP will not have this issue.