Are there limitations with advanced reporting writing via SSRS and FetchXML?

(0) Share

Report

Posted on by Cyclefitness

Can someone speak to any limitations with advanced reporting writing (for example: multi level relationships) using FetchXML and SSRS? We're hearing from the DYnamics community that the data model design has an impact in this area.

I'm very, very concerned about this given we're "done" and now needing to implement reporting and were told all along from Microsoft that you can "report on anything" using SSRS.

*This post is locked for comments

I have the same question (0)

All responses (4)

Answers (0)

Cyclefitness on at

Like (0)

Report

I've just received this from a vendor: www.kingswaysoft.com/.../Limitations-with-CRM-FetchXML.

So how can Microsoft continue to pull their "online" lever when such limitations exist? I'm really confused here.

Was this reply helpful? Yes No
Suggested answer

razdynamics 17,308 User Group Leader on at

Like (0)

Report

Hi Debra

Yes there is a tradeoff when deciding between on premise crm and online, CRM Online is limited to using FetchXML for building custom report queries, and this is not as powerful or flexible as SQL would be. FetchXML should allow to fullfill most reporting requirements but if you believe it will fall short for your customers reqs another option is to use a Replication Service that will replicate the CRM online Database to a local SQL Server or on Azure allowing to write SQL Statements instead of being limited to FetchXML.

Best Wishes, Raz

Was this reply helpful? Yes No
Jason M. Cosman 5,234 Moderator on at

Like (0)

Report

Hello Debra;

FetchXML isn't so bad, there are lots of ways to build the queries. I'd recommend taking a peek at my blog post on options to build fetchxml at [View:https://community.dynamics.com/crm/b/cosmanscrmjourney/archive/2016/03/24/options-for-building-fetchxml] .

I hope this helps some! It also talks about the sql to fetch converter!

Was this reply helpful? Yes No
Brad Sprigg 985 on at

Like (0)

Report

You certainly need to rely more on processing in the report itself rather than in the FetchXML/T-SQL layer. Being that custom code is blocked by the reporting sandbox, this can be problematic. I've especially found that aggregates in FetchXML are a little dubious and that grouping and totalling in the report itself is much more reliable. I am also a big fan of using Common Table Expressions in SQL based reports, something that isn't possible with FetchXML, ditto with subqueries.

In the end the vast majority of custom reports are possible with FetchXML but there are some notable exceptions.

Was this reply helpful? Yes No