More on MSCRM Row size limitations..

Michaeljon addresses the problem, but the message is pretty much "wait for the next release". We're leaning towards Option 3 in my previous post and possibly getting rid of those japanese yomi fields on the Contact entity that are sucking up 750 spaces of nvarchar (1500 bytes!).

 

 

3 Comments

  • Primarily my dismissal is due to the amount of custom deployment and future maintenance of a proprietary datastore.



    Also, when you open the door to using a separate database you're potentially creating solutions that will make upgrading extremely expensive, and the customer risks beeing stuck with version 1.2.



    With boxed products like MSCRM I beleive it is fair to sometimes say "it's not possible in this version" even though you know there is a technical solution.



    The business considerations weigh more heavily than the technical on this issue.

  • Option #2 also has the drawback of not being within the same transaction as the ins/upd/del on the MSCRM entity.

  • Interessante Informationen.

Comments have been disabled for this content.