Failed connection using nonstandard TCP/IP port

  • We are running SQL Server 2008 R2, and I am working on a dynamic data source (based on http://www.sqlservercentral.com/blogs/sqldbauk/2011/07/22/ssrs_3A00_-dynamic-data-sources/) that will allow the user to select the desired SQL Server Network Name/Instance Name combination at runtime.

    At this point, the report connects to all of our SQL 2008 R2 servers fine when I am using Business Intelligence Development Studio on my desktop machine. However, when I deploy the project, two of the data sources (that work fine in BIDS) fail when the report attempts to execute on the report server.

    Oddly, the two failing connections belong to a three-instance server. All three instances are named instances. The first named instance works, and SQL Server listens on TCP/IP port 1433. The second and third named instances fail, and they listen on nonstandard TCP/IP port 1443 and 1453, respectively.

    Here is the error:

    An error has occurred during report processing. (rsProcessingAborted)

    Cannot create a connection to data source 'Waits'. (rsErrorOpeningConnection)

    A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)

    I'm not sure where to look.

    Are nonstandard TCP/IP ports an issue for Reporting Services? (I tried appending ",1443" and ",1453" to the connection string in the dynamic data source. This worked in BIDS, but it still failed when executing the report on the report server.)

    Are mulitple named instances on the same box an issue for Reporting Services?

    Any other ideas?

  • Oops! I think a firewall was causing the problem. The two failed connections work on a different report server that is in the same subnet.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply