SQL Server 2008R2 SSRS reports cannot connect to data source: cannot create connection to data source

We are trying to deploy an existing SQL Server / SSRS configuration to a new set of hardware. SSRS runs on the same server as the SQL Server database with which we are trying to get reports.

Whenever we try to check any of the reports, we get an error:

An error occurred while processing the report. (RsProcessingAborted) Unable to create connection to data source "sqlConnection". (RsErrorOpeningConnection) A network-related or specific instance error occurred while establishing a connection to SQL Server. The server was not found or was not available. Verify the instance name is correct and configure SQL Server to connect remotely. (provider: Named Pipes provider, error: 40 - Could not open SQL Server connection

  • The Windows user has full rights to the server.
  • All logins exist.
  • TCP is running.
  • Named instances are beautiful.
  • SQL view service is running
  • "sqlcmd -L" displays a list of database servers

I have a complete loss.

+4
source share
2 answers

Create an udl file if it connects, the problem is the code / application, if it does not connect, then this is your firewall, connection string, DLL, the service you are running IIS on without proper permissions, etc. etc. Well, and most importantly, this is probably the connection string. Follow these steps: create an empty text file and rename it "myconnection.udl". Now double-click the file and it will launch the applet. You can set up a connection to your database and test it. (it will collect registered connection libraries, etc.). If it gives OK, then open the udl file in notepad, you will see the correct connection string. Paste in the connection settings for the application. UDL files are usually misunderstood. This is just a text file that contains connection settings. Then they invoke the dll connection. If the udl file works, then you have the correct connection string 100%

+7
source

We created a new report and deployed it, and it just worked. After some investigation, the report that I asked to use as a test initially has a parameter that connects to a completely different SQL Server by default, which the new environment cannot and should not see. All other reports work.

My hunch is that we actually fixed the problem at an early stage, when we changed the credentials of the service, but by then we were in a testing cycle against what turned out to be a listened report.

TL; DR: There was an error in the report we tested. We have already fixed the problem and did not even realize it, because, apparently, we are idiots.

+1
source

Source: https://habr.com/ru/post/1479573/


All Articles