December 1, 2009 at 12:33 am
I'm trying to use ReportBuilder 2.0 in an extranet envifonment (we service clients using our database hosting their from many parts of the country). We have a classic ASP application, and need to provide Ad Hoc reporting abilities, so it seems that Report Builder 2.0 is a natural solution. I am using the following code to launch Report Builder 2.0 on the client's computer (two variations provided for review with subsequent error message).
This methods attempts to connect directly to a data source that exists on our Reporting Services server:
http://<domainname>.com/ReportServer/ReportBuilder/ReportBuilder_2_0_0_0.application?model=http://<donainname>/ReportServer/SharedDataSource
When I click on the link, it opens Report Builder 2.0 just fine. I then click on the Table or Matrix link to open the data source. It appears in the available data sources link just fine. I click the Next button, and get the following error:
"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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)”
I'm then presented with a login dialog for the credentials for the Data Source. I supply the credentials needed by the data source and wait for authentication. After a few moments, the same error returns. When I dismiss it, it again presents the login dialog, creating what seems to be a vicious circle. The Open Datasource dialog does allow me to browse Reporting Services for other available shared data sources. If I try to access one of them, I get the same result.
The second URL I use points directly to a Model I've created from a different data source in Reporting Services.
When I try to access the data in the model, I get the following error:
"Object reference not set to an instance of an object" in reference to the RS object
Again, to be clear... this is NOT an intranet environment. We host data for detached clients through the browser. Any ideas at all will be greatly appreciated.
December 1, 2009 at 11:51 am
Unfortunately, that had no effect. I'm still receiving the same error.
December 1, 2009 at 11:55 am
then 2 callouts:
1. Your error message is whining about "Named Pipes". From external, can you see the server via Named Pipe? Try public IP address and Port.
What is /<clientname>/ .. if that is a local reference then I don't think that will work.
December 1, 2009 at 12:04 pm
More..
http://<domainname>.com/ReportServer/ReportBuilder/ReportBuilder_2_0_0_0.application?model=http://<donainname>/ReportServer/SharedDataSource
Is that a typo, or are you not including the .com in your model= ?
FWIW - I'm running a similar scenario to you..multi-tenant app with RB ad-hoc access. It requires 2 logins, the first, to the location of the stored data source, the second, to the datasource (SQL/SSAS) itself. These can be saved..but hopefully that explains the 2 hops/authentication rounds that need to be done over the internet/extranet.
December 2, 2009 at 7:31 am
I used sqlcmd -L from the computer I'm trying to connect from on the network to list the servers available. The machine I'm trying to connect to is in the list of available server.
<clientname> is just something I used to replace the directory within Reporting Services that has the connections I'm trying to use. It has no specific meaning.
December 2, 2009 at 7:36 am
The ommission of the .com extension is just a typo.
I'm using NTLM access control to the Reporting Services directory and SQL security for the connection. When the link is followed, it requires the NTLM account to access the directory that contains Report Builder 2.0. Once supplied, the report builder starts downloading as expected. The issue is once report builder is downloaded, I'm getting the error when I try to access the connection to provide data to the matrix/table. If you are providing RB through extranet access, perhaps you're doing something that I'm missing...
December 2, 2009 at 8:30 am
so you can connect to the model file, but the underlying datasource has authentication issue?
what is the authentication in the model..if it's SSPI that won't work.
For test, create a windows id that can access your model source. Try logging in with that.
In our setup, you have to authenticate first to access the connection file. The actual DS is not using SSPI, so the next pop-up is for windows credentials to the data source.
Also, have you tried connecting to a DS that is not a model to see if that is your issue?
FWIW, I stopped using models a while ago...I've logged several bugs with MS that have yet to be corrected (mostly pertaining to interop with SharePoint and SSAS and permissions)...and it is clear their future direction will provide no enhancement to model functionality...this may not be what you want to hear, and a bit off topic, but you may want to look into filtered connections to your DW or OLAP store instead of models..
December 2, 2009 at 8:53 am
Thanks. I'll try that a little later today and let you know what happens.
December 2, 2009 at 10:21 am
Okay...
I created a windows account. I granted that account access to the directory that contains the Report Builder file. I added the account to SQL Server, granting it access to the database that contains the data. I then added the account to Reporting Services, granting it basic access, including Report Builder access. I then altered the data source to require Windows Logon account. Now, when I try to access the data source (I'm not using models either), I get the following error again:
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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
This is the same error I've been getting all along. Perhaps I'm missing some configuration issue. I've reviewed my SSRS configuration and it all seems correct. I've also verified the roles, and they are all in good shape. Any other ideas?
December 2, 2009 at 11:40 am
I am at a loss. Since it is still whining about named pipes or remote access, the last things I would check are:
-remote access enabled for SQL server in ssms props
-connect via tcp/ip either ip or name that resolves in DNS rather than machine name
-tcp ip enabled in SQL. Server config
-firewall settings for SQL server ports
-tcpip connectionstring in your stored ds also
December 4, 2009 at 11:27 am
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply