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!).
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.
As long as you can work around these fields beeing enabled for replication it's probably possible, although not even close to easy.
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....)
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.
Sehr wertvolle Informationen! Empfehlen!
backlog on sharepoint, crm, office, .net development, architecture and more..