locked
Audit history entries when updating entities via plugin RRS feed

  • Question

  • Hi, I've noticed that committing updates via API appears to include every field requested on the entity and not just those that were updated. For example, I have a QueryByAttribute request in which I load 4 columns from a Contact; I update one of those fields, then submit an Update request. In audit history, it always shows all four fields as having been updated, even though only one changed value. What am I doing wrong? Is there a specific way to perform an update that only records the modified field? The only way I have figured out to do this is to load the entity (again) by ID, with only my column to update in the ColumnSet. I feel like I must be missing something. Thanks, Matt
    Friday, December 14, 2012 12:58 PM

Answers

  • This is how CRM is designed to work. It is the responsibilty of the calling code to only send attribute values that have changed - CRM will not compare before and after values for you.

    The general design pattern is, rather than submit the Entity that is returned by the Query, create a new instance of an Entity, set the Id property, and only set the attributes that you're changing, and pass this to the Update method


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    • Marked as answer by Matt Lavallee Friday, December 14, 2012 1:23 PM
    Friday, December 14, 2012 1:07 PM
    Moderator

All replies

  • This is how CRM is designed to work. It is the responsibilty of the calling code to only send attribute values that have changed - CRM will not compare before and after values for you.

    The general design pattern is, rather than submit the Entity that is returned by the Query, create a new instance of an Entity, set the Id property, and only set the attributes that you're changing, and pass this to the Update method


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    • Marked as answer by Matt Lavallee Friday, December 14, 2012 1:23 PM
    Friday, December 14, 2012 1:07 PM
    Moderator
  • Well, that is what I was doing as a workaround, but it gets pretty tedious in code, especially when there are conditional updates based on other field values. I've also noticed that the LINQ provider introduces a lot of SQL locking and have had to abandon using that as a query mechanism. Really, this means I'm calling the same entity at least three times in one PostUpdate method, just for the sake of controlling audit history. Thanks for the reply, though. -Matt
    Friday, December 14, 2012 1:23 PM