locked
RDLC vs RDL Revisited RRS feed

  • Question

  • I have searched the archive of this forum, and based on some previous answers have read the followin FAQ

     

    http://www.gotreportviewer.com/

     

    However, even so, I still have a questoin about when to use RDLC vs RDL from the point of view of licensing and load sharing betwee DB and report server.

     

    1. As we all know that SSRS will take a license of SQL Server if the web service is deployed on any other machine other than SQL Server (which is normally the case because no serious DBA will allow IIS apps to be installed on the DB Server). Also, if the SSRS is deployed on NLB cluster then each node of the cluster would need a "SQL Enterprise" license. (which can be very expensive). 

    2. Co deploying the SSRS with SQL Server is a bad idea because it puts excessive load on the DB+Report Server. 

    3. Since there is no "load balancing" in SQL all the rendering has to be done by the SSRS service which is running on the DB Server.

     

    Now compare this to RDLC

     

    1. RDLC gives me the same engine as RDL

    2. However it has no licensing tags to it.

    3. I can deploy ASP.NET report viewer on my web farm and scale it out as much as I like.

    4. Extract data from the DB using stored procedures.

     

    So it seems that RDLC solution is cheaper, gives better scale out capabilities and also moves the rendering of reports on the web farm rather than the Report Server.

     

    Why should me or anyone else choose RDL at all?

     

    There seems to be one disadvantage that the data has to fetched programmatically and manually binded (like an ASP.NET app) as RDLC does not provide any feature to connect to data sources. But this is not much when you see the cost and scalability benefits.

     

    regards,

    Abhishek.

    Tuesday, May 8, 2007 7:01 PM

Answers

  • You have some great reasons for using RDLC.

    A few off the top-of-my-head advantages for using RDL rather than RDLC.

    1.  Subscriptions
    2.  Caching / Snapshots
    3.  Role Based security
    4.  "My Reports"
    5.  Configuration / Definitions stored in Report Catalog DB
    6.  Additional rendering formats
    7.  Sharepoint webparts integration


    Without a doubt you can implement similar functionality in your application hosting the RDLC, but these are out of the box when you're using the report server.

    I have had several clients start out heading down the road of wanting to use RDLC to avoid the licensing fees.  In the end, they all ended up using the report server.  There's no one size fits all solution and in many cases, RDLC would be a valuable choice.

    Hope this helps.
    Wednesday, May 9, 2007 9:24 PM

All replies

  • bump!
    Wednesday, May 9, 2007 4:18 PM
  • You have some great reasons for using RDLC.

    A few off the top-of-my-head advantages for using RDL rather than RDLC.

    1.  Subscriptions
    2.  Caching / Snapshots
    3.  Role Based security
    4.  "My Reports"
    5.  Configuration / Definitions stored in Report Catalog DB
    6.  Additional rendering formats
    7.  Sharepoint webparts integration


    Without a doubt you can implement similar functionality in your application hosting the RDLC, but these are out of the box when you're using the report server.

    I have had several clients start out heading down the road of wanting to use RDLC to avoid the licensing fees.  In the end, they all ended up using the report server.  There's no one size fits all solution and in many cases, RDLC would be a valuable choice.

    Hope this helps.
    Wednesday, May 9, 2007 9:24 PM
  • Thanks, I also found information on the MSDN site.

     

    http://msdn2.microsoft.com/en-us/library/ms345248.aspx

     

    regards,

    Abhishek.

     

     

     


    Thursday, May 10, 2007 3:28 PM
  • Hello abhishek...
    We were just about to start using RDLC but There is an issue...with RDLC
    http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/a5f67556-7223-492f-b8d8-77b118b2cb2c ]

    But there is an issue we came to know that There is no print button in RDLC web reports. This Sux out to  vaccum yaar....Look what they write (in bold)
    [http://msdn.microsoft.com/en-us/library/ms251693.aspx]
    • The ReportViewer Windows Forms control always uses the print functionality of the client operating system. Clicking the Print icon on the report toolbar opens the common Print dialog box, initialized with the printers configured on the client computer.

    • The ReportViewer Web server control, when used with server reports, provides an ActiveX print control that you can use instead of browser print functionality. In contrast with browser print functionality, the print control allows you to print all of the pages of a paginated report, without the page information that some browsers add to the printout. Depending on browser settings, you might need to download and configure the control.

    • The ReportViewer Web server control, when used with client report definition (.rdlc) files, does not provide built-in print support. Although you can use the browser print functionality, you might achieve better results if you export the report to PDF or Excel and then print from the PDF viewer or Excel.

    Obiviously If I start printing reports by browser print feature I will also get all the buttons the reportviewer component get printed. and what if the user does not have PDF installed. are we making a high-school project...???

     Please mention this major difference on ReportViewer and Reporting services diffenrece page...and save some chaos...

    • Proposed as answer by abhisharma Friday, January 9, 2009 10:26 AM
    Friday, January 9, 2009 10:24 AM
  • Hello abhishek...
    We were just about to start using RDLC but There is an issue...with RDLC
    http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/a5f67556-7223-492f-b8d8-77b118b2cb2c ]

    But there is an issue we came to know that There is no print button in RDLC web reports. This Sux out to  vaccum yaar....Look what they write (in bold)
    [http://msdn.microsoft.com/en-us/library/ms251693.aspx]
    • The ReportViewer Windows Forms control always uses the print functionality of the client operating system. Clicking the Print icon on the report toolbar opens the common Print dialog box, initialized with the printers configured on the client computer.

    • The ReportViewer Web server control, when used with server reports, provides an ActiveX print control that you can use instead of browser print functionality. In contrast with browser print functionality, the print control allows you to print all of the pages of a paginated report, without the page information that some browsers add to the printout. Depending on browser settings, you might need to download and configure the control.

    • The ReportViewer Web server control, when used with client report definition (.rdlc) files, does not provide built-in print support. Although you can use the browser print functionality, you might achieve better results if you export the report to PDF or Excel and then print from the PDF viewer or Excel.

    Obiviously If I start printing reports by browser print feature I will also get all the buttons the reportviewer component get printed. and what if the user does not have PDF installed. are we making a high-school project...???

     Please mention this major difference on ReportViewer and Reporting services diffenrece page...and save some chaos...

    MS is atleast intelligent enough to provide a feature to export the report into XL format or PDF format by default,though it has not provided export into any other formats.So no additional PDF drivers need to be there in the client machine.I hope every machine today has at least adobe PDF reader installed. The statement can be found here ReportViewer Features

     




    • Proposed as answer by SastryKVS Wednesday, June 29, 2011 1:20 PM
    • Unproposed as answer by SastryKVS Wednesday, June 29, 2011 1:33 PM
    Wednesday, June 29, 2011 1:11 PM