SaltyBlog

Telerik Reporting Review

Posted on 25. Jun, 2012 by Eric in Database, Other, Programming

When it comes to using a Report Writer in my applications, I had heard talk for years that I should avoid Crystal Reports if possible. “It’s a behemoth.” Some said. “It’s more that you need.” “It’s frustrating.” Well up until recently I was able to remain happily ignorant of the power and fury that is Crystal Reports. And then I inherited an application that used it.

At first I thought, hey this isn’t too bad. It can do a lot of neat things. Sure it’s kind of unwieldy and all … Holy Mother what are all of these references I need to include in my project to make sure this all works?! Then the compilation errors started coming. Then the massive client installs of the runtimes. Then the runtime errors (SMAgentAPI.dll not found). And whatever you do don’t change the target .Net framework or the “bittedness” from 32 to 64 or the whole wheel of insanity starts spinning again.

I had quickly had enough.

I considered reverting to the native .Net Report Writer, which I’d had some experience with – also mostly frustrating. Between the convoluted way data sources are added to the report (and the bug that requires you to modify the report’s XML to correct issues) and the requirement that Internet Explorer be used for any decent resulting HTML output, I was ready for another alternative.

A little research led me to Telerik Reporting. The website looked good, with an active support forum, quarterly updates, and a good feature set. One feature that stood out was the ability to convert Crystal Reports report definitions. Hey, that could save me a lot of time!

The trial download process was intuitive and attractive. Before you download you must create an account on Telerik’s site, but that allows them to know exactly which products you have. This is helpful later when you login in to Telerik’s portal and see your licensed products, trouble tickets you’ve submitted, forum posts and replies.

While the product downloaded and installed, I read through the online documentation at http://www.telerik.com/help/reporting/overview.html. Follow that link and you’ll see their product is very well documented, making it quite easy to get up and running quickly. Later I needed to search for some information in the help site and found it useful as a reference as well.
Soon I was ready to begin my first report. I wanted to convert that existing Crystal Report if I could, but quickly ran into a roadblock: The report I inherited was in a version of Crystal Reports that was more recent than Telerik’s converters could handle. A quick search of the support forums found this:
Note: Crystal Reports for Visual Studio 2010 is not supported as the CrystalDecisions.Enterprise.Framework and CrystalDecisions.Enterprise.InfoStore assemblies are no longer shipped.

A note from Steve on the Telerik team helped put it in perspective as well:
"The converters are just a helper utility we did out of good will to save users some time. They do not guarantee a one-to-one complete conversion and you've already notices that there are some parts (items/sections) that have no analog on our end and vice versa. All of the converters are created before the introduction of Table/Crosstab item and have not been updated to reflect these changes yet. Thus currently reviewing and fixing the converted reports manually is highly recommended."

So, even if I had been able to convert the Crystal Report, there would have been much work to perfect the report. Maybe starting from scratch is the best option after all.

And it turns out it isn’t a bad option whatsoever. When you add a new Telerik report to your project you can walk through Telerik’s wizard. This gets the report’s data source and styling up and running quickly. One quirk of the wizard is that it always creates a stylesheet for your report, which you may not want. I’ll explain more about that in a second.
The Report Designer surface is an absolute pleasure to work with. As expected you can quickly drag fields from the Data Explorer on to the report and add the usual assortment of report objects from the Toolbox, including a BarCode object which I haven’t seen in other products.

By far the best feature of Telerik Reporting in my testing was its intuitive use of CSS-Like Styles. Rather than formatting each object individually, which can be a major pain when you have a lot of them on a report, you can create a StyleSheet on the report with named styles. You can then set the StyleName property of the object and it will automatically get the features specified by that Style. If you’re thinking “Yes, that’s exactly how it should be!” you may be surprised to know it’s not that way in other Report Writers.

Once you’ve created a StyleSheet for a report, you can export that to an external file. Other reports can then use that external stylesheet, creating consistency across your enterprise. Fantastic!

But as I mentioned earlier this actually creates a little bit of work for you when you create a report using the Wizard, because the Wizard automatically adds a Stylesheet to your report. You can attach the external Stylesheet to your new report, but the internal StyleSheet will override those settings! So you have to manually remove all of the entries from the internal StyleSheet to get the consistency across reports that you want. It’s not difficult or anything, but it’s a step you have to do. It’d be nice if there was an option in the Wizard to avoid creating it altogether.

I don’t really understand how “Panel” objects are supposed to work. I was able to use them to prevent fields from floating downwards as adjacent fields expanded to fit their content…sometimes. Other times it didn’t work until I cut everything out of the panel and pasted it back in. Does the order matter? In order to test the responsiveness of Telerik, I submitted a trouble ticket with this question. They promise a 72-(business) hour turnaround and it’s only been about 72 minutes so it’s too early to tell if they’ll deliver.

Attaching data sources to reports is excellent and clear, without the quirks of RDLC files of native .Net report writer. Passing parameters from the main report into the subreport was extremely intuitive. I especially liked how you could specify default runtime parameters .

Lastly, I had no difficulty deploying my reports to the client using the normal process. No compilation errors, no client runtime setups, no runtime errors. Everything worked.

I wasn’t able to test all of the features of Telerik Reporting, like attaching to BI Data Cubes or charting, but this product was a pleasure to use with only minor quirks. Anyone stuck using Crystal or the native .Net report writer should be able to justify the acquisition of Telerik Reporting by the productivity gains and loss of frustration that you get with it.

For more info, check the Telerik website: http://www.telerik.com/products/reporting.aspx