Personalized Community is here!
Quickly customize your community to find the content you seek.
Now Available in Community - New TechTalk Videos for 2020
Read More about New TechTalks for 2020
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
I have a need of using unmapped fields on a data entity of type container. I know that there are 2 ways in using unmapped fields, either by setting the isComputed property to yes, or no.
I have created a new unmapped container field on the FMCustomer extension entity for testing. In the post load method, I am setting a value for this container, as below:
public void postLoad()
this.Age = this.calculateAge(); //integer
this.PaymentInformation = ["test1", "test2"]; //container
As you can see, there is another unmapped field of type int, which is being calculated and loaded correctly. However, the container is either loaded as null, or a system null exception is thrown.
Any ideas on how to solve this? I know that this is a new addition, possibly on update 2, and maybe it has not been implemented fully yet.
Hi Matthew Calleja,
Did you able to get solve the above issue. If yes please share your thoughts.
Thanks in advance.
Why do you want to do such a thing, Jackie?
Returning a container sounds like a very bad idea to me. It's not anything meaningful to users and it's not clear how you would want to work with such values in Excel, for example. Therefore it makes sense to me that it's not possible and I think that you should fix the design of your entity.
I'm with Martin on his suggestions to rethink your design, to completely avoid the container.
But if you can't avoid going down that road, you'll need to use a string representation of the container instead of the container.
You can use BinData::dataToString([container]) to create the string in postLoad, and in mapEntityToDataSource you can use BinData::stringToData([string]) to recreate the container.
Thanks for your valuables comments.
I have a container field in my custom table, where I am storing queries values.
As Palle said, I have created new virtual string field in my entity to replace the container. Now the import/export operations are working fine.
Also I am getting one warning while import "The xxx column can only contain 32768 characters for the entity xxx. Data longer that this limit will be truncated on import". Do you have any suggestions?
I have checked my present data in the excel file. Here my the virtual string field contains nearly 6000 characters. If the string characters reaches more than 32768 it might truncate.
Yeah, the suggestion is: Keep the string under 32768 characters. Otherwise it will be truncated in the data management framework.
I have also used this solution for storing a packed query, and I did some investigation on the size of a packed query. It has be a very complex query to reach the 32768 character limit. So it might not be a problem.
Thank you for your suggestion Palle.
Business Applications communities