views:

6967

answers:

6

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?

+4  A: 

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.

Mosquito Mike
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
+4  A: 

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
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é
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
+1  A: 

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
+1  A: 

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
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
because of the large number of bugs, I'm migrating from 2005 (RDLC) to 2008 Reporting Services (RDL)
Junior Mayhé
+1  A: 

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
+3  A: 

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