I deploy a report solution from Visual Studio report builder and upload several reports onto SSRS.
I try my connection but failed and other previous reports which used different connection setting worked.
Please see below the two connection settings: The first figure is mine and the second figure is others'. The only difference is the 'Data Source' in 'Connection String'. Can you please advice why this cause the problem and how I can fix it? If I use 'localhost' to create my data source in my local desktop, the report cannot be compiled successfully.
This issue seams with user RepoerReader.
At your local database you have crated user RepoerReader
But your remote database located 10.12.13.14 database you you do not have user RepoerReader and are you sure and make sure port is correct or your password is wrong.
I fixed the problem by the following tricks:
When you first time deploy the solution, you should set the properties properly, like figures showing. Normally, I only configured 'Debug' because I use a single server for both data source and report delivery.
Set TargetServerURL with the client end IP address unless you are on the server itself which can be 'localhost'. This would make sure you deliver the reports to the right remote server withour error.
Login the SSRS and check the data source loaded. Normally, SSRS would automatically change the IP address into 'localhost' which is good to go for report viewing. If it still was the IP address as what I described in the question, you can try to go back to the Visual Studio report builder and change the IP address into 'localhost'. Then, don't preview the report but directly deploy the solution which ensure the new data source takes 'localhost' in SSRS. For the report was ever deployed to a specified server, so 'localhost' would not make any ambiguousness and the deployment can still locate the same server to renew the stuffs in SSRS. A key thing here is to reset the 'OverwriteDataSource' into 'True'.
Hope this help. Cheers
Related
I have a Python package that I am able to run successfully on an Azure Data Science Virtual Machine. However, when I push it to Azure as a Function, I cannot successfully make a database connection. I was getting an error that the ODBC Driver 13 for SQL Server was not supported, so I changed the driver to ODBC Driver 17 for SQL Server and now I am NOT getting an error, but no data is being returned for a query that I know should return data.
Is there any other reason that data would not be returned? Firewall issues? do I need to add a binding? Do I need to separate out the connection string to feed each part (e.g., Driver, UID, PWD) into pyodbc.connect() separately? Right now I am feeding it in like this:
setting = os.environ("CONNECTIONSTRING")
conn = pyodbc.connect(setting)
This query works fine returning data when I run it on the VM using this code, just not as a Function.
(Note, this is different from my previous post regarding reading the Azure App Setting. That problem has been solved).
There are many parts where this could be breaking.
I'd suggest start by having a Profiler or Extended Events trace on your SQL Server to verify whether a connection is even being established. If not then you need to work through the the various points of connectivity to find out where it breaks. The identity, firewall, NSGs etc might all come into play here.
Once you see a connection then you can play with permissions to ensure that your query then returns your data.
Without a full picture of your infrastructure and settings it is hard to pin it down further.
Turns out it was not a database connectivity issue like I thought it was; it was a code error.
I have created a db instance (sql server ex) in my AWS account and now trying to access it via MS SQL Server Management Studio or via Visual Studio Server Explorer, but i can't, i get the errors like below:
I have added my ip address in inbound under security group as well:
I Tried all the above steps but didn't work. Even though, i have selected 'Publicly Accessible' while using visual studio, it didnt reflect in the aws console. So, the below steps worked for me. Please try this.
Note:- this is only for my testing/learning purposes. So, i made it publicly accessible. You might not enable publicly accessible if there is a security issue. If you are testing/using for learning purposes, you can follow the below approach.
Make sure your port is publicly accessible .Else you will not be able to connect.
To enable the public accesss, please follow the below steps.
Select the db instance --> click Modify
Scroll to connectivity Section, expand 'Additional configuration' section --> select 'Publicly Accessible'--> Scroll to bottom --> select update. (as shown below).
Your db instance will be in modifying state and after 2-3 minutes it will be available. Now, give it a try to connect again and you will be able to connect now.
I know similar questions have been asked before...
I am using SQL server 2005, with SSRS 2005 installed on the same box. (aka. production DB, Report DB/TempDB, Database engine, and SSRS all in the same box).
We have about 200 reports deployed in the box.
SSRS/DB is running on a W2k3 64-bit VM.
Now the problem...
Occasionally almost on a daily basis our users get the 'operation timeout' error (error in XML document....). At first I thought it was a report size problem, but then when I try the Report Manager URL (http://<>/reports), nothing appears on the browser. The only thing I can do is to recycle the Report server IIS pool and it will work again. Everytime when the 'operation timeout' happens, the Report Manager URL will not work, and I can't find any logs in IIS to indicate there's a problem.
I researched on the net and found that some people have put a dummy report as part of the SQL server agent job which runs every 10 minutes from 9-5 to 'warm up' the SSRS. The dummy report made a small connection to the DB on one row from a very small table. The operation timeout problem seems to have disappeared for 95% of time, but it still happens. Strange enough, when the operation timeout problem happens, I notice the dummy report job has also stopped working. In this case, I had to recycle the IIS pool, and start the SQL server job again, and then SSRS will work again (until the same problem happens next time)
The error I got from the SQL server job is:
System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host
However I am totally confused by how the IIS issue on the report server somehow affects the SSRS job. Maybe I am on the wrong track but that's bizzare.
My observation so far is if it takes forever for the Report Manager URL (http://<>/reports) to appear it is a bad sign that something has gone terribly wrong on SSRS.
I have also added a new task which call the SSRS Report Manager http://<>/reports URL using PowerShell in order to 'warm-up' the IIS but it does not seem to make much difference.
Can someone point me to the right direction? Thanks. WM
In the past, after much research, I've found memory allocation for SSRS to be the root of many issues. You can try this.
Add the following into the <Service> node in the rsreportserver.config file
<WorkingSetMaximum>4000000</WorkingSetMaximum>
The file is typically in c:\program files\Microsoft SQL Server\MSRS11.iMIS\Reporting Services\ReportServer
This sets the maximum memory available for the report which also set the minimum memory to 60% of the maximum.
https://msdn.microsoft.com/en-us/library/ms159206(v=sql.110).aspx
Preface: Installed SQL Server 2016 RC0 and installed and configured Reporting Services all fine, thoughts maybe on potential conflicts with existing SSRS instances?
Issue with SQL Server 2012 Reporting Services, every time I navigate through the configuration manager to either the Web Service URL or the Report Manager URL, I get the following errors:
Report Manager URL returns
HTTP 500 error
Console when opening the Report Manager URL returns
SCRIPT16389: Unspecified error.
http_500.htm (1,1)
HTML1524: Invalid HTML5 DOCTYPE. Consider using the interoperable form
!DOCTYPE html
.http_500.htm (1,1)
Web Service URL returns
The version of the report server database is either in a format that
is not valid, or it cannot be read. The found version is 'C.0.9.45'.
The expected version is '162'. (rsInvalidReportServerDatabase) Get
Online Help
Console when opening the Web Service URL returns,
GET http://localhost:8085/ReportServer_MYREPORTS 500 (Server Error)
To try and resolve this, i've already tried adding RSExecRole to RoleMembers under both ReportServer$MyReports and ReportServer$MyReportsTempDB.
Also tried recreating ReportServer database under the Config Manager, but get the following error.
Generating Database Script - Error:
Microsoft.ReportingServices.WmiProvider.WMIProviderException: An error occurred when attempting to connect to the report server remote procedure call (RPC) end point.
I can confirm that both RPC services, SSRS Services are running with no problems, and also restarted these services multiple times.
I have realised that my ReportServer$MyReports is missing the DBUpgradeHistory table.
Any thoughts?
This will fix the issue right away:
delete from dbo.ServerUpgradeHistory where ServerVersion=[The wrong or upgraded version]
In my case, there was no "ServerUpgradeHistory" table. I needed to install SSRS 2012 on a machine that already had SSRS 2016 to do regression testing for a client that doesn't want to upgrade their system.
What I discovered is that there are SharePoint settings that SSRS installs even if you don't install SharePoint or SharePoint Plugins on your box.
Here's what fixed the problem for me:
Navigate your File Explorer to C:\Windows\assembly\GAC_MSIL\
Note there are many directories in here that have nothing to do with SSRS. We will just focus on seven directories that appear to be related to this problem.
Navigate to Policy.11.0.Microsoft.ReportingServices.Alerting
Enter the assembly directory. This is usually a series of digits followed by a hexadecimal identifier.
E.G. 13.0.0.0__89845dcd8080cc91
This path will vary based on what is installed on the machine
Backup the config file in case you need to roll back changes
E.G. from a Command prompt: COPY *.config *.bak
Open the config file.
Look for the text in the newVersion attribute of the bindingRedirect tag:
<bindingRedirect oldVersion="11.0.0.0" newVersion="13.0.0.0">
Modify this to use "11.0.0.0"
<bindingRedirect oldVersion="11.0.0.0" newVersion="11.0.0.0">
Save your changes
Repeat steps 2 through 8 with the following subpaths:
Policy.11.0.Microsoft.ReportingServices.SharePoint.Common
Policy.11.0.Microsoft.ReportingServices.SharePoint.ObjectModel
Policy.11.0.Microsoft.ReportingServices.SharePoint.Server
Policy.11.0.Microsoft.ReportingServices.SharePoint.SharedService
Policy.11.0.Microsoft.ReportingServices.SharePoint12.Server
Policy.11.0.Microsoft.ReportingServices.SharePoint14.Server
Reboot your computer
I am using SQL Server Reporting Services 2012 and received this error without any known cause: The report execution eqaiekfzmk2snc55y0zrow55 has expired or cannot be found. (rsExecutionNotFound).
While I have found other posts describing problem through Google searches, the resolutions did not help me:
Restarting SQL Server, SQL Server Agent, and SQL Server Reporting services
Increasing the Execution Timeout through SQL Server Management Studio when connected to the Reporting server
Adding rs:ClearSession to the URL querystring (and trying IE, Chrome, and Firefox)
Redeploying after each troubleshooting step and retesting
I looked in the Reporting Services log file folder C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\LogFiles but I see the datestamp is over two months old and I could see nothing related to the symptom.
I looked looked in ExecutionLog3 and did not see anything related to the symptom. use ReportServer; select * from ExecutionLog3;
To find out what did work, I verified that:
The query and results are sound, as seen in Management Studio
I can preview the report in Data Tools on the server
I can view the report when remoting into the server
I only see the error when viewing the page from outside the server. This is a relatively lightweight query and result set, so I cannot believe that this problem has anything to do with execution timeouts.
I changed the name of the file and redeployed. I am able to see that report now, but this isn't a true resolution because I still don't know what is truly causing the problem and how to fix it. If the symptom appears again, I can't keep changing the filename and redeploy.
Is there a way to get a better idea of what is happening? A specific log file or a property I need to change?
Update:
I thought I had this problem worked out, but apparently not. I found nothing useful in the error logs: only a restatement of the same error message visible in the browser. When I redeploy (using SQL Server Data Tools), the error goes away... for a few hours or until the next day, when I need to redeploy to make the error go away.
I know this is an old question but I had this problem recently and it turned out to be a bad session cookie. The cookies session-id matched the guid in the error message and once I deleted the cookie all worked fine after that. The report at one point had been configured to cache a temporary copy
but that had since been turned off (however, the problem existed before that had been turned off so it may not be relevant).
Hopefully this answer will help someone else save the hour I spent figuring it out in my environment :)
This might help someone.
In my case, The report url had trailing spaces (a silly mistake) which caused this.
I've added &rs:Command=ClearSession to the end of my url and works fine with me.
As stated in a different answer you can clear the session which usually resolves this issue.
If you have a question mark in your URL already then add the following to the end.
&rs:Command=ClearSession
If you do not have one then you need to add the following to the end.
?rs:Command=ClearSession
I just had this problem, it was for an existing report that had been working correctly. However, the Report Builder had been open for some time in another window while I was working on something else, and I hadn't saved my work (I was applying a filter, and didn't want to save my changes with my test filter). It occurred to me that since the report HAD been working, but it had been sitting idle, it might have gone stale. I opened the Dataset Properties, clicked Query Designer, then "Run Query". The Query Designer then got a fresh request from the data source. I closed the Dataset Properties window and clicked "Run", and my report was again displayed.
For me, I had no trailing space.
Some people had luck with clearing Session.Keys of "Microsoft.Reporting.WebForms.ReportHierarchy"
I solved it by Session.Clear in the global.asax
For us, the error appeared trying to run a report on an SSRS 2016 server using Internet Explorer 11. The user had created a bookmark that linked directly to the report. What may have happened: IE preserves cookies and temporary internet files for favorites to "help them load faster". The user may have initially ran the report, then created the bookmark to the report which contained session information.
To fix: Delete the bookmark, then cleared browser history in IE (CTL+SHIFT+DEL) being sure to uncheck "Preserve Favorites website data".