I have a report containing 6 charts each displaying some percentages over an interval of time.
I have put all the 6 charts in a separate RDL file and using it as a sub-report in my main report which also contains a matrix.
The issue I am facing is the chart becomes too slow (>10 s of rendering) as soon as I implement the drill down functionality. Without drill down its about 1 s.
The drill down report parameters do not have any functions - I have already converted all of them to either fields or parameters.
Its not that big of an issue yet - but we have some major changes coming to the report which may increase the number of charts to about 15 - and all of them will contain drill down action. Once that's implemented the report will definitely take more than 30 s which would not be acceptable.
Any pointers would certainly help.
Thanks.
Drill downs can add a huge amount of output to a report, depending on the number and complexity of them. I've seen that each drill down in our reports adds about 2K to the size of the rendered report. Depending on how you added the drill down to the chart, every single point could be a separate link, and these add up fast.
Run the report without drill downs, and export it to .MHTML.
Run the report with the drill downs, and export it to .MHTML.
Compare the size of the outputs.
The reason for .MHTML output is that one file contains everything. The file sizes should help you do the arithmetic with regards to the number of drill in your reports and help you reduce it to an appropriate amount.
Related
I am using a simple table object in SSRS that uses the default format of Arial 10. It shows correctly in design mode, but when I execute the report, there are different fonts in different columns. Notice in samples below, during report execution, columns 1,2 and 5 are different than columns 3,5. Can someone explain this or point me in the right direction to get consistent output? Thanks!
Design Mode
Executed Report
Did you make any changes in the format?
if so, you have to clear cache by deleting the
file "reoprtName.rdl.data" in the project folder,
or rebuild the report.
I've returned to our reports collection after a couple of years away, and added a new report which has a simple tablix containing a few columns, but many rows from the dataset.
The problem is, the report (in Preview in VS, and when run on the Report Server) only shows some of the rows returned by the dataset, and doesn't enable the page navigation icons in order to scroll through the data to access the rest.
Where do I find the settings which control these things, please?
UPDATE:
Looking at some pre-existing reports, it seem that these exhibit the same problem - it would appear that SSRS can only display about 5,000 rows regardless of how many the dataset contains.
There is a 'hidden' setting in the XML code (not available via the UI AFAIK) called InteractiveHeight. Removing this line resulted in the paging starting to work
I have SQL Server 2008 R2 with SSRS. I have created an SSRS report that may contain up to 3,000,000 rows.
When I tried to generate such huge report I saw the following picture:
The stored procedure (one that brings the data into the Report) worked 50 seconds
After this the SSRS ReportingServivesService.exe started to consume a lot of memory. It's Working Set grew up to 11 GB. It took 6 minutes; and then the report generation failed with the following error message:
An error has occurred during report processing. (rsProcessingAborted)
There is not enough space on the disk.
“There is not enough space on the disk.” – this was probably about the disk drive on that server where the Windows page file was mapped into. The drive had 14 GB of free space.
A NOTE: the report was not designed as a single-page report. It is divided on pages by 40 rows. When I try to generate the same report with 10,000 rows – it takes just 1 minute.
The question is: can this be fixed somehow?
SSRS is extremely ill-suited for this kind of scenario. Tools like BCP or SSIS seem much more suited to this task. The question you ask ("can my situation be fixed") is not quite answerable, apart from being answerable by you by demonstrating that it can be done.
In my experience though, I wouldn't think of trying to get 3 million rows to work in SSRS.
If you insist or are compelled to try anyways, here's a few things you can do to improve the situation:
Dive in to the rdl and remove everything you don't need: font instructions, dimensions, images, etc. Check regularly in the designer if the file is still valid. You could even consider rebuilding the report with as little extra features as possible.
Move any expression or dynamic ssrs bit to the query.
Remove all formatting and formats for cells.
Increase disk en memory space. If you are compelled to generate such big reports in SSRS you're gonna need it. Close any other application you can, your PC or Server's gonna need all the resources it can get for this. Normally I'd consider this a non option / as an indication you need different tooling though. But I'm beginning to sound like a broken record :)
Choose the export format wisely. Excel or PDF is gonna take many additional resources, e.g. CSV renderer will be much friendlier.
I'm new to SSRS and I need the ability to group multiple reports into a single report. I've searched around a lot but not found much. I currently have two reports (more to come) that users need to be able to view/save individually. The users also need the option to view both those reports as a single report. Essentially just a simple concatenation. Eventually, there will be several reports grouped and the user will be able to render all of them for viewing online or saving as a single PDF.
I tried two sub-reports in a master report but it causes a lot of hard to diagnose page-break problems. I was wondering if there was a more straight forward option here. Thanks.
Combining all the report elements into one report would work, but the users also need to be able to view them as individual reports as well. To avoid having to maintain both an master report and multiple individual reports, you have a couple of options:
Create a master report and insert the individual reports as sub-reports. If you get page break issues, check the report page height and widths versus the subreport container height and width.
(If you have SQL Server 2008 R2 or later) Consider publishing your individual reports as a set of Report Parts. You can then reuse these in a master report.
I'm not a fan of subreports either, they work well in Crystal but are not really necessary in reporting services.
Why don't you just combine the reports into one? Copy all the tablixes / other objects from each report onto a new report. You can select all and copy and paste very easily, you just need to set up the parameters, datasets and data sources if they aren't shared.
You can set pagebreaks to occur after each tablix or a good trick is to use rectangles because they will let you control page breaks in their properties.
We are doing a conversion of Crystal Reports to SSRS. One thing we noticed was that the crystal viewer launches faster than ssrs. However, in crystal it buffers in the remaining data. To be clear, if I request 5 records run. The viewer launches in Crystal with recordset 1, however records 2-5 are not accessible till all supporting reads are complete.
In SSRS, nothing displays till records 1-5 are completly accessible to the viewer.
Giving the illusion that Crystal is faster than SSRS. In fact, I've done time tests same data same report. SSRS beats Crystal everytime in overall request completion. But Crystal displays information to the user more quickly.
Any settings or anything to mimic the behavior of Crystal on SSRS?
A little more digging revealed that the feature on the Crystal Webserver is 'page on demand' processing.
SSRS will try to do this automatically, but there are many things in the report definition that could prevent it.
I think the most likely culprits are sorting at the report level and page numbers. Move the sorts into your query, and take them out of your report definition. Otherwise, SSRS needs to retrieve all data to determine what the first row will be.
There are some nice tips on MSDN for this.