FetchXML Builder for XrmToolBox is getting more and more attention and is now downloaded and used in most parts of the world. Current numbers indicate a total download count of about 1600, and top count for a single version is close to 400. So I figured it was probably time to write an introduction to the tool, though I have actually received very few questions about how to use it (is it really that intuitive and self-explanatory??) There is now a page on this blog dedicated to FetchXML Builder with brief information on how to use the tool and what features it offers. It begins like this: Continue reading “Introduction to FetchXML Builder”
Author: Jonas Rapp
OnChange part 3: Where is the clearOnChange method?
The Microsoft Dynamics CRM SDK comes with lots of functionality to affect how CRM behaves on the client side.
In a couple of articles I will discuss the opportunities ventilate my frustration over run-time event handling manipulation.
Continue reading “OnChange part 3: Where is the clearOnChange method?”
OnChange part 2: addOnChange with context awareness
The Microsoft Dynamics CRM SDK comes with lots of functionality to affect how CRM behaves on the client side.
In a couple of articles I will discuss the opportunities ventilate my frustration over run-time event handling manipulation.
Continue reading “OnChange part 2: addOnChange with context awareness”
OnChange part 1: Remove design-time event handlers
The Microsoft Dynamics CRM SDK comes with lots of functionality to affect how CRM behaves on the client side.
In a couple of articles I will discuss the opportunities ventilate my frustration over run-time event handling manipulation.
Continue reading “OnChange part 1: Remove design-time event handlers”
FetchXML count="-1" now returns records again
Last September I highlighted a change in the FetchXML interpretation, where using syntax like…
<fetch count="-1" mapping="logical" version="1.0"> <entity name="account"> <attribute name="name" /> <attribute name="address1_city" /> </entity> </fetch>
…would not return any records. You had to use a count of “0” instead.
Now, when running CRM 2013, a count of “-1” returns records again 🙂
Perhaps someone in the product team happened to read my post and thought they should be nice to me.
That was kind.
CRM 2011/2013 Reset Sitemap problem
As you might have seen from previous posts on my blog, I am a big fan of the XrmToolBox by Tanguy, especially the Sitemap editor is excellent in its simplicity and capabilities.
However, I recently ran into a problem after using the function:
Reset CRM 2013 SiteMap to default. Continue reading “CRM 2011/2013 Reset Sitemap problem”
Dynamics CRM Tools: Tanguy, our hero
Generally I don’t blog about blogs, but now I am obliged to make an exception from that principle to write this shout-out to one of our everyday heroes down in the CRM trenches.
MS CRM 2011 UR14 Breaking Change: FetchXML count="-1" does not return any records
A change in the interpretation of FetchXML “count” attribute has been identified from Update Rollup 14 for Microsoft Dynamics CRM 2011.
In many situations when you use FetchXML you have the need to return all records available, instead of using paging or in other ways limiting the number of records returned.
Up until now, we have regularly used the method of setting the count attribute to “-1” to indicate “all records”.
<fetch count="-1" mapping="logical" version="1.0"> <entity name="account"> <attribute name="name" /> <attribute name="address1_city" /> </entity> </fetch>
This is however not a good idea if you are running CRM with UR 14. Instead, this will not return any records at all!
Setting the count attribute to “0” or completely omitting the count attribute will return all records (up to the internally set limit, typically 5000).
<fetch count="0" mapping="logical" version="1.0"> <entity name="account"> <attribute name="name" /> <attribute name="address1_city" /> </entity> </fetch>
In the documentation of the FetchXML syntax it is not stated how to use the count attribute to instruct CRM to return all records, and maybe it is just us who ignorantly have used the “-1” value until now and just us who consider the change to be “breaking”… but somehow, I don’t really think so.
Are You a Rock Star?
The Microsoft Dynamics CRM community is constantly growing, and it does so in many directions. Now we are all (who desire to sign up for it) ranked by our individual CRM Rock Star shine! Just enter your certs, projects and inspirations and – voila! – you get your ranking in your own country and globally.
Check my stats here http://crmrockstar.com/rappen and sign up to find out how much of a Rock Star you are!
MS CRM SDK 5.0.13: Xrm.Page.context.getClientUrl – at last!
The long long wait is over… Have you ever had a CRM installation that can be accessed using different URLs, e.g. one to be used inside a corporate network, and one to be used for external access?
Have you also written some javascript to make calls to the OData endpoint or to open a new entity form? Then you have realized that the context.getServerUrl method returns the URL that was assigned the server during the installation of CRM, and not the URL currently used to access CRM. Why is that a problem? Well, authenticating the user to one URL, and then having javascript making calls to the OData endpoint on another URL, will just give the user a “too bad, you are not authorized to do anything on this URL”. Now, at last, in Microsoft Dynamics CRM Software Development Kit version 5.0.13 the context.getClientUrl method is introduced, which returns the base URL currently used by the user to access the CRM application.
The getServerUrl method is still there, but deprecated and should not be used in the future. Documentation can be found here. Happy javascripting!