Broad question is: Is there anything Telerik Reporting can do that SSRS (2005) cannot?
Specifics: We're looking to migrate our current Reporting infrastructure from in-house ASP.NET + Crystal (VS Edition) to something else.
Ignoring the cost factor (we have a Telerik license), is there any pros or cons to going with Telerik over SSRS?
Key elements we need are:
generate reports from a custom ASP.NET application
schedule reports
email reports on demand or on a schedule
pdf output, drilldown html
massage the dataset in C# before passing it to the rendering engine
Any experiences or sites that point out advantages or limitations (with either engine) would be greatly appreciated.
SSRS is a server-based reporting system whereas Telerik Reporting is purely an embedded reporting tool. You should compare Telerik Reporting to SSRS ReportViewer control in local processing mode, not the whole SSRS system, unless you intend to use the SSRS server too. I think this is the first question to answer: you should evaluate the pros and cons of using a report server.
The usual reason of choosing embedded reporting is to avoid a server dependency. If you are an application developer and deploy your application to multiple sites, you would have to support multiple SSRS installation in addition to your application. Telerik reports compile to a dll that you can deploy with your application easily.
Generally, server-based SSRS is more feature-rich than Telerik reporting, especially the SSRS 2008 tablix is handy. I think that Telerik Reporting has supported crosstabs only from Q1 2009. It does not support interactive features like drilldown. You should see the known limitations of Telerik reporting and also the substantial improvements in SSRS 2008 compared to SSRS 2005. On the other hand, ReportViewer in local mode understands RDL 2005 only, so you are limited to SSRS 2005 features.
Now, it is easier to look at your requirements.
Generating reports from a custom ASP.NET application
SSRS Server: Microsoft ReportViewer web control configured for remote processing views the reports processed and rendered by an SSRS server
SSRS local mode: Microsoft ReportViewer processes and renders the local RDL 2005 report definitions
Telerik: Telerik ReportViewer processes and renders reports. Reports can be deployed as a single dll with all the resources (images etc.) embedded. This is the strong point of Telerik reporting.
Scheduling reports
SSRS: Server-side feature, not supported in local mode
Telerik : Not supported
Email reports on demand or on a schedule
SSRS : Server-side feature, not supported in local mode
Telerik: Not supported
Pdf output
SSRS: Various output formats in server mode. In local mode, ReportViewer supports only Excel and PDF
Telerik: Various output formats, including pdf
Drilldown html
SSRS Server: Drilldown to a subreport (another RDL report definition) with parameter passing, static urls in report elements
SSRS local mode: Static urls but no interactive features
Telerik: Static urls but no interactive features
Massage the dataset in C# before passing it to the rendering engine
SSRS Server: Supports report datasets defined in RDL, OLEDB compatible
data sources, XML data, Integration Services packages and standard .NET providers
SSRS local mode: This quote is directly from Lachev's book (p.525):
ReportViewer supports two types of
data sources in local processing mode:
a dataset that contains an ADO.NET
DataTable object or an enumerable
collection of business objects.
ReportViewer Windows Forms also
supports binding to instances of
System.Windows.Forms.BindingSource and
to System.Type. Report Viewer Web
server supports binding to an instance
of System.Web.UI.IDataSource.
Telerik: any DataSet or DataView can be set as a datasource at runtime
Given your key elements, and assuming that you are doing internal reporting inside a corporate firewall, I'd definitely recommend using an SSRS server. Try to get one SQL Server 2008 licence or use SQL 2008 Express as a reporting server. But if you absolutely have to use embedded reporting, Telerik is probably a better choice, at least until Microsoft ReportViewer supports RDL 2008 in local mode. This new ReportViewer should be shipped with Visual Studio 2010.
For SSRS, I recommend reading Teo Lachev's Applied Microsoft SQL Server Reporting Services. Sample chapters are available at the book's site the and in Google Books.
Telerik Reporting has excellent support too. Developing Telerik reports relies heavily on samples and support forums.
I have also written blog posts on embedded reporting and Telerik Reporting in particular.
Just adding to mika's reply regarding Telerik interactivity:
Their reporting now offers a few interactivity features, namely navigating to a subreport (drill-through), navigate to a bookmark, and navigate to URL. Their current roadmap mentions that they will add interactive sorting and drill-down by the end of 2011. These should bring their reporting product much closer to SSRS in this regard.
I want to add some new information about Telerik's solution.
Some of the things that were previously not supported, such as Scheduling reports and Email reports on demand or on a schedule are now available as part of the Telerik Report Server product. The Report Server comes with the Report Designer mentioned above. More information about if is available here.
One of the main reasons we stopped using SSRS and went with Telerik is because Telerik has much better support across browsers. Naturally, one would not expect MS to provide equal support for a rival product when it comes to browser compatibility.
Since you are planning one doing a web based application this may be a factor.
I first started using Telerik reporting version 2010 Q2 and never had an issue linking reports over a web app to provide drill-down or linking functionality. It was quite simple and intuitive.
Another thing to think about is that SSRS report files which are RDL files, whereas a Telerik report is compiled into your app. If you need to change your report you'll need to recompile and redeploy your app. For RDL files, you simply upload them to the SSRS server. I still prefer Telerik though, even though it means a slightly longer SDLC for a change request.
Another thing that grinds my noodle is that as long as we used SSRS we had to have both VS 2008 and 2010 installed, because VS 2010 does not have support for designing RDL reports like 2008 has (BIDS is basically a scaled down version of VS 2008: Visual Studio 2010 Reporting Services Projects? )
With Telerik we can stick to using VS 2010.
Comment on "Telerik Reporting has excellent support too. Developing Telerik reports relies heavily on samples and support forums.":
No. You're making an assumption. I have created many complex reports without needing any direction from forums/sample/etc - its a very intuitive tool. I am sure there are many developers out there who have been able to do just fine without "heavy" reliance on the forums/samples - its not rocket science, it's cake.
SSRS Local mode is not supported in Azure.
In the latest versions Telerik Reporting have Report Designer that is tool like Report Builder and the report viewer support XML report definitions (trdx). So no compiling is required if you change the reports.
Related
Sorry for being a newbie to SSRS.
My design goal:
Near term: develop - using SSRS - a simple client side (no reporting server!) report - based on MS SQL data tables, and embed it into the .NET WPF client (application)
Long term: for additional reports, hire external SSRS experts, so they will provide the reports developed, and I will integrate them into the same WPF application.
I managed to do 2 things:
Develop a simple report connecting to MS SQL, using Reports Builder 3.0 - as a result, an RDL file was generated (the file contains all the DB connections)
Embed a ReportViewer WinForms control into the WPF application.
Unfortunately, I wasn't able to load the report I developed, into the application.
I understood from articles on the new that RDL is not designed to support client-side execution (without a server), and RDLC should be used instead. However, I wasn't able to figure out how to conver the report to RDLC, using the Reports Builder - it does not give me an option to save in a different format.
I would appreciate any hint from the experienced people on how to accomplish my goal.
Specifically, should I use RDLC, and if positive - what's the way to get the report in this format?
Thanks
Max
I would recommend using Visual Studio when creating RDLC reports that will be embedded within an application and run in "Local" mode, and using either Microsoft Report Builder or Visual Studio to create RDL reports that will run in "Server" mode within SSRS.
A RDLC report would be created within a WPF Visual Studio project be simply creating a new Report.
A RDL report would be created within a Reports Server project when using Visual Studio.
Alternatively, it appears you could simply rename the file from RDL to RDLC if you don't mind manually correcting the Data Source information in the report definition file: http://msdn.microsoft.com/en-us/library/ms252109(v=vs.120).aspx.
We are planning to use SQL Reports in our company and we are currently evaluating the ways to expose the reports to end users. Should we use a reporting web service and then render the reports through a .NET Application? Should we use a report viewer or should we expose the SQL GUI to the users? What are the pros and cons of these over each other? Could anyone please help? I couldn't find any information anywhere for this.
The simplest is to use the Report Manager website that is enabled by default with an SSRS installation it's very quick and easy to get running and the security/ snapshot(cache) / subscription (email etc) options are easy to configure on a per site /per folder /per report basis. It's drawbacks are:
It's ugly - although if you are good with CSS it is possible to mess
with it, but I wouldn't. Newer versions e.g. 2008R2 and 2012 are less ugly
It has an ugly URL - although you could use a DNS alias to get
around that
It doesn't let you control how parameter drop-downs and other
objects appear on the page, but that's minor
I usually use Sharepoint (MOSS not WSS) (if the company has that) with the report viewer web-part. It doesn't require any special Sharepoint SSRS integrated mode - you can read about that but it's that's not a path I recommend taking.
The reports then appear to be embedded within the company's existing intranet site which looks professional IMO. Powerview for sharepoint is also a good option (or performance point in older versions of Sharepoint)
I would definitely NOT go down the road of webservice, that would entail a huge amount of unecessary programming. If you have a lot of spare .NET developers around I still wouldn't do that.
Rather to use the report viewer object in Visual Studio to display a report in an .NET web application. Designing reports using the BIDS (2008R2 and earlier) or SSDT (2012) is much easier than programming, particularly if you've used other reporting tools such as crystal reports or even Access. Using that report viewer object is a much better option than rolling your own.
I've written my response in order of easiness and work required. Hope that is helpful.
I have an Access db file, and I need to slice and dice the data for various reports that my boss wants.
Is Microsoft Reporting Services a tool that is appropriate for this kind of activity?
If so, would I import the Access data in SQL Server, then the reporting services is a tool that works on SQL Server, allowing the report builder to build custom reports?
SSRS is great for what your trying to do if you wish to stick with Micrsoft tech.
SQL Server Express Adv edition comes with report server. There are plenty of guides out there for install / set up but once going you can use a little application called Report Builder that lets you design the layout of the reports themselves.
Reporting server esentially generates reports from templates you produce in report builder app.
The free edition of report server that comees with SQL Express Adv can export reports into three types, word files, excell or PDFs and does a very good job at it. It also exposes a webservice with a whole myrad of web methods thats very very usefull. ASP.Net also has a control which you can drop into your apps which will render a report.
So in short, yes :)
Hope this helps.
I have been studying SSRS 2005 / 2008 in the past weeks and have created some server side reports. For some application, a colleague suggested that I look into RDLC for that particular situation. I am now trying to get my head around the main difference between RDL and RDLC.
Searching for this information yields fragmented information at best. I have learned that:
RDLC reports do not store information about how to get data.
RDLC reports can be executed directly by the ReportViewer control.
But I still don't fully understand the relation between the RDLC file and the other related systems (the Reporting Server, the source database, the client).
In order to get a good grasp on RDLC files, I would like to know how their use differs from RDL files and in what situation one would choose RDLC over RDL. Links to resources are also welcome.
Update:
A thread on the ASP.NET forums discusses this same issue. From it, I have gained some better understanding on the issue.
A feature of RDLC is that it can be run completely client-side in the ReportViewer control.
This removes the need for a Reporting Services instance, and even removes the need for any database connection whatsoever, but:
It adds the requirement that the data that is needed in the report has to be provided manually.
Whether this is an advantage or a disadvantage depends on the particular application.
In my application, an instance of Reporting Services is available anyway and the required data for the reports can easily be pulled from a database. Is there any reason left for me to consider RDLC, or should I simply stick with RDL?
From my experience there are few things to think about both things:
I. RDL reports are HOSTED reports generally. This means you need to implement SSRS Server. They are a built in extension of Visual Studio from SQL Server for the reporting language. When you install SSRS you should have an add on called 'Business Intelligence Development Studio' which is much easier to work with the reports than without it.
R eport
D efinition
L angauge
Benefits of RDL reports:
You can host the reports in an environment that has services running for you on them.
You can configure security on an item or inheriting level to handle security as a standalone concept
You can configure the service to send out emails(provided you have an SMTP server you have access to) and save files on schedules
You have a database generally called 'ReportServer' you can query for info on the reports once published.
You can access these reports still through 'ReportViewer' in a client application written in ASP.NET, WPF (with a winform control bleh!), or Winforms in .NET using 'ProcessingMode.Remote'.
You can set parameters a user can see and use to gain more flexibility.
You can configure parts of a report to be used for connection strings as 'Data Sources' as well as a sql query, xml, or other datasets as a 'Dataset'. These parts and others can be stored and configured to cache data on a regular basis.
You can write .NET proxy classes of the services http:// /ReportServer/ReportingService2010 or /ReportExecution2005. You can then make up your OWN methods in .NET for emailing, saving, or manipulating SSRS data from the service directly of a Server hosting SSRS reports in code.
Programmatically Export SSRS report from sharepoint using ReportService2010.asmx
Downsides:
SSRS is kind of wonkey compared to other things on getting it up fast. Most people get confused by the security policy and designing reports as an 'add on' to VS. SQL 2005 = VS BIDS 2005 , SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010(LOL).
Continuing on 1 the policy for security settings IMHO are idiotically overcomplex. There is server security, database security and roles, two security settings on the page hosted for the service. Most people only set up an admin than can't get in and wonder why other users cannot. Most common complaint or question on SSRS is related to getting in generally from my experience.
You can use 'expressions' that will supposeduly 'enhance' your report. Often times you do more than a few and your report goes to a crawl in performance.
You have a set amount of things you can do and export to. SSRS has no hover over reporting I know of without a javascript hack.
Speed and performance can take a hit as the stupid SSRS config recycles the system and a first report can take a while at times just loading the site. You can get around this by altering it but I have found making a keep alive service for it works better.
II. RDLC reports are CLIENT CONTAINED reports that are NOT HOSTED ANYWHERE. The extra c in the name means 'Client'. Generally this is an extension of the RDL language meant for use only in Visual Studio Client Applications. It exists in Visual Studio when you add a 'reporting' item.
Benefits of RDLC reports:
You can hookup a wcf service much much much more easier to the dataset.
You have more control over the dataset and can use POCO classes filled with Entity framework objects or ADO.NET directly as well as tables themselves. You can monkey with the data for optimization it before binding it to the report.
You can customize the look more with add on's directly in code behind.
Downsides:
You need to handle parameters on your own and while you can implement wrapper methods to help the legwork is a little more than expected and unfortunate.
The user cannot SEE the parameters in a 'ReportViewer' control unless it is in remote mode and accessing an RLD report. Thus you need to make textboxes, dropdowns, radio buttons on your own outside the control to pass to it. Some people like this added control, I do not personally.
Anything you want to do with servicing the reports for distribution you need to build yourself. Emailing, subscriptions, saving. Sorry you need to build that in .NET or else implement a proxy that already does that from above you could just be getting using hosted reports.
Honestly I like both for different purposes. If I want something to go out to analysts that they use all the time and tweak for graphs, charts, drill downs and exports to Excel I use RDL and just have SSRS's site do all the legwork of handling the email distributions. If I want an application that has a report section and I know that application is its own module with rules and governance I use an RDLC and having the parameters be smaller and be driven by the decisions the user made before getting to the report part of what client they are on and site and then they usually just choose a time frame or type and nothing more. So generally a complex report I would use RDL and for something simple I would use RDLC IMHO.
Q: What is the difference between RDL and RDLC formats?
A: RDL files are created by the SQL
Server 2005 version of Report
Designer. RDLC files are created by
the Visual Studio 2008 version of
Report Designer.
RDL and RDLC formats have the same XML
schema. However, in RDLC files, some
values (such as query text) are
allowed to be empty, which means that
they are not immediately ready to be
published to a Report Server. The
missing values can be entered by
opening the RDLC file using the SQL
Server 2005 version of Report
Designer. (You have to rename .rdlc to
.rdl first.)
RDL files are fully compatible with
the ReportViewer control runtime.
However, RDL files do not contain some
information that the design-time of
the ReportViewer control depends on
for automatically generating
data-binding code. By manually binding
data, RDL files can be used in the
ReportViewer control. New! See also
the RDL Viewer sample program.
Note that the ReportViewer control
does not contain any logic for
connecting to databases or executing
queries. By separating out such logic,
the ReportViewer has been made
compatible with all data sources,
including non-database data sources.
However this means that when an RDL
file is used by the ReportViewer
control, the SQL related information
in the RDL file is simply ignored by
the control. It is the host
application's responsibility to
connect to databases, execute queries
and supply data to the ReportViewer
control in the form of ADO.NET
DataTables.
http://www.gotreportviewer.com/
I have always thought the different between RDL and RDLC is that RDL are used for SQL Server Reporting Services and RDLC are used in Visual Studio for client side reporting. The implemenation and editor are almost identical. RDL stands for Report Defintion Language and RDLC Report Definition Language Client-side.
I hope that helps.
From my experience, if you need high performance (this does depend slightly on your client specs) on large reports, go with rdlc. Additionally, rdlc reports give you a very full range of control over your data, you may be able to save yourself wasted database trips, etc. by using client side reports. On the project I'm currently working on, a critical report requires about 2 minutes to render on the server side, and pretty much takes out whichever reporting server it hits for that time. Switching it to client side rendering, we see performance much closer to 20-40 seconds with no load on the report server and less bandwidth used because only the datasets are being downloaded.
Your mileage may vary, and I find rdlc's add development and maintenance complexity, especially when your report has been designed as a server side report.
Some of these points have been addressed above, but here's my 2-cents for VS2008 environment.
RDL (Remote reports): Much better development experience, more flexibility if you need to use some advanced features like scheduling, ad-hoc reporting, etc...
RDLC (Local reports): Better control over the data before sending it to the report (easier to validate or manipulate the data prior to sending it to the report). Much easier deployment, no need for an instance of Reporting Services.
One HUGE caveat with local reports is a known memory leak that can severely affect performance if your clients will be running numerous large reports. This is supposed to be addressed with the new VS2010 version of the report viewer.
In my case, since we have an instance of Reporting Services available, I develop new reports as RDLs and then convert them to local reports (which is easy) and deploy them as local reports.
If you have a reporting services infrastructure available to you, use it. You will find RDL development to be a bit more pleasant. You can preview the report, easily setup parameters, etc.
While I currently lean toward RDL because it seems more flexible and easier to manage, RDLC has an advantage in that it seems to simplify your licensing. Because RDLC doesn’t need a Reporting Services instance, you won't need a Reporting Services License to use it.
I’m not sure if this still applies with the newer versions of SQL Server, but at one time if you chose to put the SQL Server Database and Reporting Services instances on two separate machines, you were required to have two separate SQL Server licenses:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/
You can Bing for other similar blogs and posts regarding Reporting Services licensing.
For VS2008, I believe RDL gives you better editing features than RDLC. For example, I can change the Bold on a selected amount of text in a textbox with RDL, while in RDLC it's is not possible.
RDL: abcd efgh ijklmnop
RDLC: abcd efgh ijklmnop -or- abcd efgh ijklmnop (are your only options)
This is because RDLC is using a earlier namespace/formatting from 2005, while RDL is using 2008. This however will change with VS2010
If we have fewer number of reports which are less complex and consumed by asp.net web pages.
It's better to go with rdlc,reason is we can avoid maintaing reports on RS instance.
but we have to fetch the data from DB manually and bind it to rdlc.
Cons:designing rdlc in visual studio is little difficult compared to SSrs designer.
Pro:Maintenance is easy.
while exporting the report from we page,observed that performance gain compared to server side reports.
if you want to use report in asp.net then use .rdl
if you want to use /view in report builder / report server then use .rdlc
just by converting format manually it works
I'm after a tool to generate decent-looking documents from templates, that needs to:
be invoked through code (not interactively)
run on Windows, ideally invoked from code within a web-server
process standalone* report files that contain their own internal data definitions, query options, etc (i.e. ideally so that we can push simple report files to the server, and it simply work - where report/document maintenance is not necessarily a developer activity)
access data from a database (SQL Server 2005) based on parameters (ids etc) that we pass in
export (again, through code) to pdf or similar
*= where standalone simply means that the report is fully self-describing; it is fully expected that additional reporting runtime components will be required to execute the report. Contrast to rdlc which uses the data-sets from the local VS project.
I looked at the rdl/rdlc options (Visual Studio 2008), but rdlc seems to be coupled to the assembly (not standalone), and rdl seems to lack the code-based export ability. The version of Crystal Reports included in VS2008 seems very similar to rdlc - presumably the full Crystal Reports offering has more functionality, but has a non-trivial price tag too...
I'd welcome any suggestions for an appropriate, professional looking tool that might be suitable and recommended...
I think SQL Reporting Services fully support all of your requirements.
I have build some sophisticated solutions myself with SSRS.
(Example)
Fully manageable through code (via SSRS WS) (Upload, execute and export Reports)
Used SQL Server as database
Queries are defined in RDL (or Stored Proc) and based on parameters
There are other solutions like Telerik Reporting or Data Dynamics ActiveReport, but they are not free.
Let me know if you need more informations
SSRS WS: With that I mean the Web Service Interface (Report Server Web Service
). There is also a URL Access method, but I don't think it's a solution for you
I dont think you can satisfy all requirements. Number 3 especially is the killer.
On one reading, I see it as adhoc reporting generating it's on SQL. On another, it is giving users "empowerment" to do roll their own within some limits you define?
You may have looked already... but have you thought about using the ReportBuilder functionality to set up the basics and leave users to do the rest? You'll need a report monkey at some point anyway to set soemthing up.
Edit, after comment:
Reporting Services it is then.
It comprises a web service that renders RDL files uploaded from VS.
Report Builder is a template for users to hack and bash their own within the limits and environment you set.
Architecture of RS 2008
Our Data Dynamics Reports product sound like it is for you. It is a fully programmable reporting component for .NET / Visual Studio. View the documentation on the API here. You can export the reports to any of our various formats, including PDF, HTML, and Excel and it also includes an end user designer control that you can embed into your own applications to let end users modify or create their own reports.
The reports are stored in RDL - the same XML dialect that Reporting Services uses - in fact you can take any existing RDL files and open them in Data Dynamics Reports. In addition to compatibility with RDL, we add many more features, such as "themes" to consistently style your report, master reports (think ASP.NET master pages for reports), and several other built in controls such as a calendar, barcode, and dashboard controls to name a few.
Now lets look at your requirements one-by-one and see how Data Dynamics Reports might solve them:
be invoked through code (not interactively) - Data Dynamics Reports includes comprehensive API.
run on Windows, ideally invoked from code within a web-server - You can use Data Dynamics Reports in client-based, or ASP.NET applications, it even support medium trust ASP.NET applications (webservices are fine).
process standalone* report files that contain their own internal data definitions, query options, etc (i.e. ideally so that we can push simple report files to the server, and it simply work - where report/document maintenance is not necessarily a developer activity) - Data Dynamics Reports uses standard RDL (not rdlc) which includes all information bout how to retrieve data from your datasource. We also include an end user designer control to allow you to emebed a design environment for these standalone files into your own applications.
access data from a database (SQL Server 2005) based on parameters (ids etc) that we pass in - Data Dynamics Reports includes comprehensive support for parameters (even get the "valid values" from a query.
export (again, through code) to pdf or similar - Data Dynamics Reports supports exporting to PDF, HTML, Excel, Word, images, and XML.
I hope it works out for you, and let me know if you have any additional questions.
Scott Willeke
Data Dynamics / GrapeCity inc.
I think, based on all the criteria, you likely need to look at Crystal Reports, since you want the reports to be standalone, although, you could also create a report designer out of XtraReports or ActiveReports Pro and have much of the same functionality.
As for running it on the fly and having it generate, distribute, and archive the reports that run, check out our product at www.versareports.com. It should work with any .NET report designer you want to use and provides the enterprise-class report server framework you likely need.