locked
Data Concurrency in CRM RRS feed

  • Question

  • Hi All,

    Data Concurrency in CRM

    In CRM, how do we prevent when multiple users attempt to modify data at the same time?

    Anyone had implemented any kind of logic or any thoughts on this.

     

    Thanks

    Tom

    Friday, May 8, 2009 2:54 AM

Answers

  • I don't think there is much that's particularly effective that you can do. You don't get any control over the locking mechanism at the platform end
    You could try implementing an optimistic locking mechanism by the following:
    1. Record the time when the record was read - ideally I'd use the server time in a plugin on Retrieve, and put it into a custom attribute
    2. Ensure this custom attribute is on the entity form, and that it's value is always submitted (use ForceSubmit = true)
    3. In a pre-event on the update message, compare the time at which the record was read, against the lastmodifiedon value. If lastmodified is after the read time, cancel the save

    I expect this could work, but I'm not sure you're creating more problems than you're solving. Step 2 has to be carefully written to avoid spurious saves when only the read time has changed, and in step 3 you can't identify whether the previous update affected different attributes from those the user is saving, and there is no way to give the user the option to save anyway. I also don't think this is absolutely bullet-proof as you are only implementing the optimistic locking logic in the platform, not at SQL Server, so there's a latency issue that I don't think you can get round.


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk
    Friday, May 8, 2009 9:18 AM
    Moderator

All replies

  • Guys.. please put some thoughts. I am sure someone must have done something.
    Friday, May 8, 2009 6:55 AM
  • I don't think there is much that's particularly effective that you can do. You don't get any control over the locking mechanism at the platform end
    You could try implementing an optimistic locking mechanism by the following:
    1. Record the time when the record was read - ideally I'd use the server time in a plugin on Retrieve, and put it into a custom attribute
    2. Ensure this custom attribute is on the entity form, and that it's value is always submitted (use ForceSubmit = true)
    3. In a pre-event on the update message, compare the time at which the record was read, against the lastmodifiedon value. If lastmodified is after the read time, cancel the save

    I expect this could work, but I'm not sure you're creating more problems than you're solving. Step 2 has to be carefully written to avoid spurious saves when only the read time has changed, and in step 3 you can't identify whether the previous update affected different attributes from those the user is saving, and there is no way to give the user the option to save anyway. I also don't think this is absolutely bullet-proof as you are only implementing the optimistic locking logic in the platform, not at SQL Server, so there's a latency issue that I don't think you can get round.


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk
    Friday, May 8, 2009 9:18 AM
    Moderator