More on MSCRM Row size limitations..

Published 10 August 04 07:51 PM | madsn

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!).

 

 

Filed under:

Comments

# KjellSJ said on August 10, 2004 02:32 PM:

What an interesting design choice to add special, long yomi_ fields for allowing Japanese "SOUNDEX immitating" functionality into the ContactBase table (even if it where really small to begin with).

The yomi_ fields are teoretichally ideal candidates for removal or length trunc'ing, but this will require a lot of "you're on your own" stuff and is hard to accomplish due to the MSCRM database being bound to the replication database used by the "Sales for Outlook" client.

I can't wait for your description of how to get rid of the yomi_ fields.

# Mads said on August 10, 2004 02:36 PM:

As long as you can work around these fields beeing enabled for replication it's probably possible, although not even close to easy.

# Brad Corbin said on August 16, 2004 02:10 PM:

I'm curious about your dismissal of #2: Use a Proprietary Data Store

This would obviously be impossible to replicate to the Outlook client for offline access, but is there more to it than that?

(I'm thinking here of custom 1-to-Many tables, which are unsupported in the current product)

It would be up to me to design the ASP page to pull the data and display it correctly, but what other concerns do you have with this approach? (Not that I've tried it yet, of course....)

# Mads said on August 17, 2004 03:47 AM:

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.

# KjellSJ said on August 20, 2004 10:24 AM:

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

Leave a Comment

(required) 
(required) 
(optional)
(required) 

This Blog

<a name="MyWork">!My work!</a>

Funstuff

Goodies

MSCRM Blogs

Sharepoint

Useful reading

Weblogs

Syndication