120

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?

Daan
  • 6,816
  • 4
  • 26
  • 37

10 Answers10

85

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:

  1. You can host the reports in an environment that has services running for you on them.
  2. You can configure security on an item or inheriting level to handle security as a standalone concept
  3. You can configure the service to send out emails(provided you have an SMTP server you have access to) and save files on schedules
  4. You have a database generally called 'ReportServer' you can query for info on the reports once published.
  5. 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'.
  6. You can set parameters a user can see and use to gain more flexibility.
  7. 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.
  8. 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:

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. You can hookup a wcf service much much much more easier to the dataset.
  2. 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.
  3. You can customize the look more with add on's directly in code behind.

Downsides:

  1. 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.
  2. 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.
  3. 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 it's 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.

I hope that helps.

Community
  • 1
  • 1
djangojazz
  • 12,570
  • 9
  • 48
  • 82
57

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/

Matthew Lock
  • 11,495
  • 11
  • 84
  • 122
  • Can I Use custom objects (`List` of `MyEntity`) as the source for Remote Reports (***RDL***), ***not RDLC*** ? – Kiquenet Nov 17 '15 at 14:06
23

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.

Noctis
  • 10,865
  • 3
  • 38
  • 74
Mosquito Mike
  • 962
  • 1
  • 7
  • 17
  • 3
    I couldn't get my head around the 'client-side' part, until I realized that with RDLC it is possible (even required) to manually provide the data to the report, without forcing a connection to some database. – Daan Jul 07 '09 at 13:29
16

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.

marr75
  • 5,583
  • 1
  • 22
  • 39
  • I'm thinking here would be best, regarding performance, to put RDL reports in a remote server with Reporting Services running. You don't need to update each of your customers workstations (you just have to update one report in one site only). There's a memory leak in 2005 version and some minor bugs that seems to be avoided when using reporting services. – Junior Mayhé Jun 18 '10 at 19:59
  • 1
    I'm not positive what you're trying to say. We already found the best performance using client side reporting. RDLs on a remote server were a big bottleneck for us. – marr75 Jun 24 '10 at 19:35
  • 3
    This very much depends on a) the relative processing capability of the report server and b) whether your report viewer controls are configured for local or remote processing. By using report viewer controls in local processing mode you are transferring the report processing work to the client, which may be beneficial in a situation where the report server does not have capacity to handle the workload (e.g. if there are many clients). However a reasonably well spec'd report server should be able to handle most report workloads. Other bottlenecks can be report/query design and data sources. – Nathan Griffiths Dec 11 '12 at 20:26
  • 1
    As of the time I answered this, server side reports did't handle concurrent users very well, basically just handling one request at a time (I'd be very surprised if this has been enhanced at all). Furthermore, in our environment (and many others I'd have to assume) the rendering of the report is a very minor detail compared to the work done by the database server. Client side reports gave us a lot more control over the concurrency aspects of the application. It does add additional complexity to the system, however. So, it's an engineering decision to be made. – marr75 Dec 13 '12 at 21:39
  • @marr75 -- Server vs Client scale differently. With server side, you're more likely to hit a brick wall as you hire 25 employees and they all hit the server at once. With client side, all 25 get their own PC to help carry the burden, so you may not hit any brick wall at all -- as your company grows, the server side solution requires more babysitting. That said, you can optimize the server more, and that only needs to be done at one place -- I'm thinking building the right indexes -- involve your DBA. My preference is to use client side, but optimize both for max.performance! – MicroservicesOnDDD Jun 05 '20 at 17:53
11

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.

Harrison
  • 163
  • 2
  • 5
7

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.

Shawn Eary
  • 560
  • 5
  • 18
  • 3
    SQL Server licensing still requires you to have a license for every machine that has ANY component of SQL Server installed. Therefore a scale-out deployment where the report server databases are on a different server to the report server service requires a separate license for each server. – Nathan Griffiths Dec 11 '12 at 20:19
7

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.

Kevin Fisher
  • 715
  • 6
  • 7
2

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

avgbody
  • 1,342
  • 3
  • 15
  • 31
  • 4
    This is not because of the difference between rdl and rdlc, this is a difference between sql server reporting services 2005 and 2008. The report viewer redistributables, which lag behind sql server development, support client side reporting, this lag is the reason for the difference you're describing. – marr75 Feb 15 '10 at 16:52
  • 1
    because of the large number of bugs, I'm migrating from 2005 (RDLC) to 2008 Reporting Services (RDL) – Junior Mayhé Jun 18 '10 at 20:01
1

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.

WingsOfFire
  • 21
  • 4
-3

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

mahendramaid
  • 25
  • 9
  • This appears to have RDL and RDLC swapped around in terms of where they're run - and even if it didn't, this wouldn't add anything useful to the tens of existing answers. – underscore_d Nov 16 '17 at 18:57
  • rdlc is extensión for reporting local, you can use in aspnet, winforms or wpf. https://msdn.microsoft.com/es-es/library/ms252104.aspx. You cannot use .rdlc files in remote processing mode – dgzornoza Dec 05 '17 at 12:56
  • In terms of modifying are these the same? Both can be edited in the Report Builder? – Mark May 07 '21 at 18:30