Thursday, February 4, 2016

Get out of the habit of using new ColumnSet(true); in your Dynamics CRM .NET Code

Do you use new ColumnSet(true); to quickly pull all of the entity columns in one swoop.  Many times, unless a plugin gets run too often there is little impact on the system and it can seem innocent enough.  I have definitely been guilty in the past of this one myself and I want to share one situation where it can bite you in the rear.

So you are new to a specific CRM installation and you have been tasked to write a plugin to perform some task.  You need to update some fields in the account entity based on the data that's already on the entity.  You decide to use new ColumnSet(true); instead of pulling just the attributes you explicitly need to perform the intended function of the plugin, because heck, as developers we can be lazy sometimes and it takes longer to write out all the schema names you need for the specific attributes.

What you don't know is that the company's GP partner has an integration to GP that runs when a specific field on the account is updated.  Even if you don't change the value of that field, the system still sees it as an update because that attribute is now included in the entity you just updated... because you were lazy.

And you can replace the word "you" in that last paragraph with "I" because that's what I just did today. Whoops!

- Happy Thursday!

3 comments:

  1. well caught! me too lazy sometimes :) Yes performance also goes slow in complex custom development.

    ReplyDelete
  2. Agreed... this is one of those situations for which I have been meaning to run SQL Profiler to view the impact. I would love to see the effect on the DB between choosing a few attribs vs * when you have custom indexes.
    This can also make an impact on plugin Image registrations. Bringing back a plugin image with all attribs can have the same impact.
    I am also uptight about registering for all attribute changes vs only those you care about... This does not seem to be a common issue with developers but its' definitely something to keep in mind!

    ReplyDelete
  3. Hm, while that is of course true, I have learned (painfully :D) early on that it's never a good idea to use the update call for a retrieved entity. I consider a best practice for myself to create a new object with just the fields I need updated.

    ReplyDelete