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.
After much gnashing and wailing seems like Report Builder uses information in definitions in Report Server to then run queries locally by itself, and not through Reporting Services.
My mistaken belief was that when I did something like Refresh Fields when setting up a Dataset, Report Builder was going through Report Services to get the relevant output and/or metadata. This seems to not be the case.
I had defined the connection string of the shared data source as Data Source=(local);Initial Catalog=<database name>. Now, this works when you are in Reporting Services' browser interface, but Report Builder seems to read the connection string and use it for itself. Reporting Services on my local development machine does not have any of the setup on the target server running these reports, so anything I would use will fail.
Changing the connection string to Data Source=<server name>;Initial Catalog=<database name>, instead of localhost, allowed Report Builder to work properly. (RB still popped up "Enter Data Source Credentials". I used my Windows credentials, which is a valid login on the target server.)
Best Answer
Yes, I've seen this. You can set the Credential and Connection Information such that a report is run impersonating the unattended user account. This article explains how to set up this type of report running. This setup is especially useful if you want to use the credentials inside a dynamic connection string (for example when you need to insert the credentials through a parameter).
If you don't want to run using the unattended user account, you should review your DataSource and connection string as defined in the report. Perhaps play around with the settings and different configurations for the datasource to create a different setup. The above links should be a start for some documentation.