2
votes

My SSRS rdl report is rendering differently in the ReportViewer in an ASP.NET application than it does in BIDS (for this project we are on SQL Server 2008 R2 and BIDS). It renders the way I want it in BIDS, but the Report Viewer changes the placement of some of the textboxes. Specifically, it's pushing some text boxes down the page and creating a large area of whitespace.

I am using version 10.0.0.0 of the report viewer DLL.

Running the report in the ReportManager web UI in SSRS displays the report the same way as in the Report Viewer (not the way we want it).

BIDS is on SQL Server 2008 R2 SP3.

Ideas on how to mitigate this?

3
Please add screenshots of your report design and the rendered output in both Visual Studio and the ReportViewer.iamdave

3 Answers

2
votes

SSRS report elements when rendered in certain formats such as HTML cannot overlap in any way, whereas in the VS/Report Builder preview or formats such as PDF they can.

Due to this, if you aren't very careful to avoid these overlaps in your design you will see a different layout in the ReportViewer where SSRS has 'pushed' your report items around to remove the overlap.

2
votes

We have similar issues, but different versions of SSRS. This page and many similar ones give information about rendering, but none of them seem to answer the questions "does this text fit in this box?" and "How big will this box be?" Rendering to IE, Chrome, Safari, Word, and PDF was an exercise in frustration and compromise, especially considering that Visual Studio and Report Builder were also different. In all cases, the height and width of the text boxes changed, the font size changed, the spacing around the text changed.

Our technique was to prioritize the various output formats, then find settings that produced the best output based on those priorities. Given this, users see better (but still not quite perfect) results than we see in Visual Studio.

1
votes

I was able to find a solution for our particular problem by minimizing scenarios where SSRS will resize an element during rendering. For example, we had a text box that had the default height on the canvas (roughly the height of one row of text). The text had an expression with HTML content that included several line breaks. This caused SSRS to resize the textbox and push other elements down the page, even though there was space to fill without moving other elements. When I increased the height of the textbox on the canvas to fill the available space, SSRS stopped moving other elements around on the page.

My lesson learned is to set the size of an element on the canvas based on how big it is likely to be when it's rendered. If SSRS decides it needs to increase the size of an element, it starts moving other elements around on the canvas (even if there is space to fill without moving things around).