Ultimate solution (works in SSRS 2012 too!)
Append the following script to the following file (on the SSRS Server)
C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportManager\js\ReportingServices.js
function pageLoad() {
var element = document.getElementById("ctl31_ctl10");
if (element)
{
element.style.overflow = "visible";
}
}
Note: As azzlak noted, the div's name isn't always ctl31_ctl10
. For SQL 2012 tryctl32_ctl09
and for 2008 R2 try ctl31_ctl09
. If this solution doesn't work, look at the HTML from your browser to see if the script has worked properly changing the overflow:auto
property to overflow:visible
.
Solution for ReportViewer control
Insert into .aspx
page (or into a linked .css
file, if available) this style line
#reportViewer_ctl09 {
overflow:visible !important;
}
Reason
Chrome and Safari render overflow:auto
in different way respect to IE.
SSRS HTML is QuirksMode HTML and depends on IE 5.5 bugs. Non-IE browsers don't have the IE quirksmode and therefore render the HTML correctly
The HTML page produced by SSRS 2008 R2 reports contain a div
which has overflow:auto
style, and it turns report into an invisible report.
<div id="ctl31_ctl10" style="height:100%;width:100%;overflow:auto;position:relative;">
I can see reports on Chrome by manually changing overflow:auto
to overflow:visible
in the produced webpage using Chrome's Dev Tools (F12).
I love Tim's solution, it's easy and working.
But there is still a problem: any time the user change parameters (my reports use parameters!) AJAX refreshes the div, the overflow:auto tag is rewritten, and no script changes it.
This technote detail explains what is the problem:
This happens because in a page built with AJAX panels, only the AJAX panels change their state, without refreshing the whole page. Consequently, the OnLoad
events you applied on the <body>
tag are only fired once: the first time your page loads. After that, changing any of the AJAX panels will not trigger these events anymore.
User einarq suggested this solution:
Another option is to rename your function to pageLoad. Any functions with this name will be called automatically by asp.net ajax if it exists on the page, also after each partial update. If you do this you can also remove the onload attribute from the body tag
So wrote the improved script that is shown in the solution.
Best Answer
I would guess that your build is bad you are deploying and did not get updated from either a change you made or it is not overwriting a value. You can do a few things to ensure default parameter values are there.
Go the published report on the server and click the drop down arrow on the right and choose 'manage'. Now choose 'Parameters' on the left pane. Under the 'Has Default' column (3rd from left on 2008R2 and higher) it should be checked. Then under 'Default Value' it is either a specific explicit input or it will say 'Query based' meaning it derives its value from a dataset or similar manner. If this is different than your value you would expect and is explicit you can just change it here.
If it is query based and you observe that your data cannot be altered here I would go to BIDS and open up the SSRS project under the solution and choose to 'Open Folder in Windows Explorer'. Find your report's DATA file and delete it. Note this is NOT the report itself but a file similar to it like 'report.rdl.data'. This is NOT a step that most likely affects the build but merely the preview, however we wish to see the preview after the rebuild exactly as it would be. Go to your report's project and choose 'Clean' then 'Rebuild' to ensure you are removing all the data files in the bin in addition to the one you did explicitly. Rebuild will now build all the files from the instructions. Now click preview on your report, verify it is as expected with defaults. Publish again and observe.
If this still did not change the report I would guess the updates are not taking. I would rename the report on the server like 'report_old' and try to publish again.
If this still did not take I would check that the publish location we want is valid and we are deploying correctly and that any parameters are not getting data from shared datasets that are not set to 'do not overwrite' or weird edge cases resulting from publishing being halted due to config settings.
SSRS has had weird issues for me in the past with the issue of my files being under source control and then the system not wanting updates to parameters myself. Generally this is fixed with a rebuild but sometimes it does require a new binary file to be published.