Opening large reports in SSRS 2016 takes a long time after migratting from SSRS2012


  • Hi,

    W're facing the following problem. W're testing to migrate from sql2012 to sql2016.

    Opening a report with VS2013 it's going very quick, opening the same report in SSRS 2016 with VS 2015 takes up to 10 minutes.

    The size of the report is 5mb

    After the report is open in sql2016, we deploy the report to the reportserver(we changed the webconfig, <httpRuntime executionTimeout= "9000" maxRequestLength="2097151" />).

    Report is running fine but after opening again in VS2015 is takes again 10 minutes.

    Opening the report with the latest Report Builder is takes even longer.

    Are more people facing the same problem, what will be a solution to solve this issue

    Wednesday, September 21, 2016 11:39 AM

All replies

  • Hi Axians,

    As you mentioned, you deployed the report to the report server 2016, did you mean upload the report definition file directly to the report server 2016, or opened the report in a Report Designer in Visual Studio 2015 then deployed to the report server 2016, right?

    If you upload the report definition file directly to the report server 2016, that means the report doesn’t upgrade, the report definition remains in the original schema. But once you open the report in Report Designer in Visual Studio 2015, the report definition is upgraded to the currently supported RDL schema. Reference: Upgrade Reports

    So, you’d better upgrade the report and deploy the report to report server, then use the report execution log to find out how many time is spent among data retrieveral, report processing and report rendering sections.

    Use ReportServer
    Select * from ExecutionLog3 order by TimeStart DESC

    After you determine whether the delay time is in data retrieval, report processing, or report rendering, use this article to help troubleshoot issues.

    And, you found that the report was running fine on the report server, but token long time in Visual Studio 2015. That because the Visual Studio and Report Manager don’t render exactly the same way. SSRS puts the data (for example :calculations, expression, etc) from the data source into its own internal format and then renders it into whichever format the user desires. Visual Studio will, from time to time, render the reports slightly different than Report Manager. That may be a cause.

    If you still have any questions, please feel free to ask.

    Best Regards,
    Pirlo Zhang

    Thursday, September 22, 2016 9:21 AM
  • Hi Prirlo,

    Thanks for your reply:

    Maybe I didn't explain it very well.

    Opening the report in SQL2012 with VS2013  is working fast. So no preview just opening

    Opening the same report in SQL2016 with VS2015 is very slow(takes up to 10 min). Report is about 5mb. Smaller reports are working fine. Untill this moment I didn't run the report, so no data was validated.

    After the report opened in VS2015 we deployed it to the report server. If I look into the rdl the reportdefinition in the header is now 2016.

    After that I tried to open the deployed report with report builder it takes again up to 10 minutes.

    Thursday, September 22, 2016 9:37 AM
  • Hi Axians,

    If you just opened the report slowly in Visual Studio 2015, I think the issue may be caused by the tool. When you opened the report with Visual Studio 2015, in fact, you opened the tool firstly and then loaded the report. Though you didn’t preview the report, you remained retrieving the data of the report and loaded the data into the Visual Studio 2015.

    As you mentioned, the report is about 5mb, it may contain complex queries or graphs ,that will spent a few time. The CPU or Memory also have an effect on the performance at the same time.

    Then you opened the report in the report builder, did you mean open the report in the report builder application or open with Paginated Report in the report server ?

    Best Regards,
    Pirlo Zhang
    Friday, September 23, 2016 9:53 AM
  • Hi Pirlo,

    Strang thing is that report opens in VS2012 directly en in VS2015 takes up to 10 minutes

    Same problem for ReportBuilder

    Just opened the report on the server with reportbuilder not through the portal

    Friday, September 23, 2016 10:49 AM
  • Hi Axians,

    I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated. 

    Thank you for your understanding and support.

    Pirlo Zhang

    Friday, September 30, 2016 6:38 AM
  • Hi Axians,

    What Pirlo shared before is a good method. We can enable execution logging first, then re-open the report on both SQL 2012 with VS 2013 and SQL 2016 with 2015(Or run it in report builder).

    After that, running the following statement and then compare the results with the values of TimeStart/End, TimeDataRetrieval, TimeProcessing and TimeRendering.

    Use ReportServer

    select * from ExecutionLog3 order by TimeStart DESCReport Server Execution Log and the ExecutionLog3 View:  

    Meanwhile, did you test any other report which is larger than 5MB?


    Friday, September 30, 2016 10:23 AM
  • Hi has anyone found a solution to this ? I am having a very similar issue where an RDL file opened in VS2010 shell very quickly (~3 secs) but when I try to open the same file within VS 2015 professional, and it takes 5 minutes to just open the file.  If I leave all of the datasets and remove all of the content (tables, fields, etc..) on the report, it opens quickly, so it appears to be having a hard time displaying the content
    Monday, October 03, 2016 9:42 PM
  • Hello,

    The issue Axians is talking about has nothing to do with executing or previewing the report in VS/ReportBuilder/SSRS, so ExecutionLog3 investigation makes no sense. 

    It's just about opening a report in VS 2015 or in the ReportBuilder 2016 (designer mode). 

    Opening a large report (> 1 MB) with many and very large tablixes in ReportBuilder 3.0 or VS2012 is just a matter of seconds. In VS 2015 or ReportBuilder 2016 is takes sometimes more than 15 minutes dependent of the size of the report. Meanwhile the CPU is 100% busy. 

    When you load the report in the new tools, it will be converted to the new SSRS 2016 XML format. I can imaging this takes some time. However opening an already converted report takes also a very long time.

    And yes, it happens with multiple reports. 

    According to me, it's just a matter of debugging the piece of code that is responsible for parsing the XML in the designer.



    Friday, October 07, 2016 12:53 PM
  • 15 minutes to just open the RDL? Have you tried opening it on another workstation? There's definitely something wrong. Please share a sample report xml if possible.
    • Edited by TUSG Friday, October 07, 2016 1:29 PM
    Friday, October 07, 2016 1:28 PM
  • Yep, I've tested the report on several workstations. Even with clean installs of sql 2016.

    But  I can send you a report so you can experience it yourself and hopefully you will hace s solution for me?

    Friday, October 07, 2016 1:31 PM
  • I would be interested in testing this as well if possible. Can you replicate the issue creating the report going against Adventure Works or Wide World Importers dataset and then send the RDL file for review and testing?

    If so, share OneDrive link to the RDL file or email the file to me for testing at


    Dan English's BI Blog

    Sunday, October 09, 2016 3:37 AM
  • Dan,

    I've send you a email, thanks for the help

    Wednesday, October 12, 2016 8:14 AM
  • Hi Erwin,

    Did you ever find a resolution to this? Currently experiencing the same problem with SQL Server 2014 reports on VS 2015. Only seems to be occurring for certain reports.



    Monday, February 20, 2017 11:55 AM
  • Hi Joe,

    Yes we did, we got a fix from Microsoft: After installing the reports where opening fine.

    • Proposed as answer by joejgriffin Monday, February 20, 2017 8:41 PM
    Monday, February 20, 2017 12:27 PM
  • Hi,

    Thanks for the quick response - that fixed it!



    Monday, February 20, 2017 8:42 PM