I was assisting one of my co-authors and colleagues, Jim Pletscher, with Reporting Services 2012 running on our new SharePoint 2013 Farm (so integrated mode of course using the Reporting Services Service Application). We have two (2) dedicated servers that only run Reporting Services.
One issue was that when running a report we would get a connection issue but after hitting F5 (once or twice) the report would eventually render as if nothing was wrong. Therefore I thought maybe one of the Reporting Services servers was acting funny as when one server was accessed it was fine but when the other server was accessed, things weren't right.
We left that one alone as we were getting a similiar issue consistently when attempting to pass parameters into the report rendering via the URL. Investigating the logs, I found the following:
Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: , Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot create a connection to data source 'REPORTS_DW'. ---> System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
There are tons of posts out there with "System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances" mostly involving .NET Framework 2.0 and Hotfixes. I was sure it couldn't be that.
I stumbled upon a related post but dealing with Excel Services 2010 here where the guy was saying to restart the services. After goofing my Search Service Application previously by trying to restart services, I only totally reboot servers now. So I was going to do that, however, I noticed in the comments of that post that some other guy said restarting the services did not work and that IISReset did the trick.
I was doubtful but decided to try IISReset first on both servers. I waited for the service to come back and I ran the original report without parameters: that worked fine. Next I clicked on the link in the report that contained the report URL with the parameters - it now worked without any issues!
I am glad it was a simple fix but I was hoping for something a little more complex as there is no explanation of why this would happen. If it happens again I am going to suspect an SSRS app pool issue.
One issue was that when running a report we would get a connection issue but after hitting F5 (once or twice) the report would eventually render as if nothing was wrong. Therefore I thought maybe one of the Reporting Services servers was acting funny as when one server was accessed it was fine but when the other server was accessed, things weren't right.
We left that one alone as we were getting a similiar issue consistently when attempting to pass parameters into the report rendering via the URL. Investigating the logs, I found the following:
Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: , Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot create a connection to data source 'REPORTS_DW'. ---> System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
There are tons of posts out there with "System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances" mostly involving .NET Framework 2.0 and Hotfixes. I was sure it couldn't be that.
I stumbled upon a related post but dealing with Excel Services 2010 here where the guy was saying to restart the services. After goofing my Search Service Application previously by trying to restart services, I only totally reboot servers now. So I was going to do that, however, I noticed in the comments of that post that some other guy said restarting the services did not work and that IISReset did the trick.
I was doubtful but decided to try IISReset first on both servers. I waited for the service to come back and I ran the original report without parameters: that worked fine. Next I clicked on the link in the report that contained the report URL with the parameters - it now worked without any issues!
I am glad it was a simple fix but I was hoping for something a little more complex as there is no explanation of why this would happen. If it happens again I am going to suspect an SSRS app pool issue.
This is really a nice blog with great post, I would really like to keep reading here. Thanks for this nice article, valuable information for all and of course I will recommend my friends to read this for sure.
ReplyDeleteHI i have configured SSRS 2012 in Sharepoint 2013 with service application.
ReplyDeletewhen I create a New data source in sharepoint data source library and click' test connection' . no result comes. if i put connection string with "Integrated security = true or sspi' then i will get this error " 0x80131401".
My sharepoint web applcation pool account and SSRS service accounts are different.. and I gave permission to external data source in another domain sql server to these accounts. I am not getting connection successfull.
Do we still need to give report server URL in sharepoint 2013 similar to sharepoint 2010 in general settings? or any other configuration in SSRS service application
You need to specify an Execution Account. I would use the SSRS service account. Make sure you include the domain in the Account text box (domain\serviceaccount).
Delete