I was adding fields to an existing entity, and one field I accidentally made a money field rather than a float. So, I went back and deleted the field and recreated it as a float. No big deal. Well, it is a big deal if you have ever had multiple currencies in your system. All of a sudden, users were getting the infamous "Object reference not set to the instance of an object." error. I looked on the server and found that the error was coming from the following plugin:
Microsoft.Crm.ObjectModel.MultiCurrencyPlugin
That wasn't any plugin I had ever put on the server so I was surprised to see it. As it turns out, once a money field is added to an entity within a system that has ever utilized multiple currencies, there must ALWAYS be a money field on the form. Otherwise you get the above error. I tried deleting the extra currencies in the system to see if that would fix the problem; it didn't. I guess something changes once you add more than one currency that doesn't change back. I ended up in having to add a money field to the entity. I didn't put it on the form, and I'll never use any data from it, it's just there to prevent that error from popping up. Awesome.
Hopefully this helps someone else.
David Fronk
Dynamic Methods Inc.
4 comments:
MSCRM sure can cause some unusual errors when removing fields from a form. I have found it best to never remove a field from a form once I have added to the form. Instead, I create a tab called HIDE, which is hidden by javascript during the onload event of the form, and then move the fields I want to really delete to this HIDE tab. This prevents "strange" errors from occurring on the form; however, this does have a few drawbacks.
1. The load time of the form is increased, since more data is being loaded
2. Since CRM 4.0 has a finite number of tabs that can be used on a form I am using what could potentially be a needed tab
Depending on the situation, the second issue can be removed by instead creating a group on the form on the first tab, or any tab for that matter, called HIDE and then using JS to hide the group when the page loads.
Either way, sorry to hear about your troubles with addressing your issue. I just wanted to give you a few thoughts on what I have done to prevent errors from occurring because CRM was looking for a particular field or type of field on a form.
2.
Thanks for the tips, I'll keep those in mind. There are lots of ways to handle these situations, hiding them on a tab definitely works. But just knowing which fields will have repercussions on the entity can go a long way. Either way, typically the end user doesn't want to see them, so you're still stuck with hiding them.
David Fronk
Dynamic Methods Inc.
I agree it would be nice to know which fields will have repercussions. Other than the SDK do you know of an easy means that I can use to identify which fields have "requirements".
I was looking for the advantages/disadvantages with money-fields and ran into this post...
And I agree with David Fronk. Users do not want to see unused attributes/hidden fields when they are building reports or AF views. As far as the removing of attributes or recreating them for deletion : why not take advantage of making backups of your customizations/environment?
Post a Comment