Hello everyone,
I posted the same issue before, but I couldn't find the solution yet. I am posting this agian cos I tried almost everything and I am not able to solve the issue.
Let me explain what is happening here:
Server A - is my development local machine
Server B - is the remote reporting server, where all reports are deployed
Server C - is where the databases are located
- After successfully deploying the project (the reports and datasources) on the remote server and try to run the report , I am getting the following error message
- I tried to deploy and run the same report on my local machine report server(Server A), which is still accessing the same database from Server C. This works fine.
So from this we can understand that A ==> B ==> C is not working, however A ==>C works fine(using Server A as a report server).
I almost tried all the possible solutions that are posted on the forum, such as storing the credential information on the report server (server B), created a data source, which is not a shared data source, on the report server level e.t.c. and I ended up with nuthin.
The weired thing is that there are existing reports that are already created and deployed(by somebody else) in the report server (server B) , which access the database on Server C. These existing reports run with no problem, even I can create a report which uses the existing data source and runs perfectly. However, when I create a new report which uses a different data source (from Server C), and deploy it to Server B and tried to run it, the above error message comes.
Please let me know if you have any idea.
Thx.
What type of data source is it, and how are you connecting? OLEDB, ODBC? Are you using Windows Authentication for the data source?|||If you are using windows integrated security this could be the "double hop issue". Try to connect to Server B via remote desktop and start the report. If it works you have to mark the server b as "trusted for delegation" in your active directory. I am actually not sure if this is enough, but you can also google this problem. there are also some KB entries (at least for ASP .NET) concerning this problem.|||Actually, the data source is Microsoft SQL Server type. And for the authentication I stored the login and password securely on the report server.
|||Are you using SQL Server or Windows authentication?|||I have the same problem, when trying to change the datasource on reports deployed from Visual Studio. It seems that if you change the data source before deploying, then that is okay and the connection works. Changing the data source within Reporting Services is where I get the trouble.
I develop the reports on a development server against a test database on the same server. Then I change the datasource in visual studio to a staging data source, and deploy the reports. I go to the reporting services server and run the reports, and they are fine. At this point the reports have my blessing to become the "live" reports, so all I need to do is change the data source on them to the live production database server. But doing that only makes the reports fail. If I go back to the development server and change the data source there and redeploy, the reports work.
This is only a problem for me when I am trying to change to a firewall protected data source which is not accessable from the development machine. I'm really interested if anyone has a solution for this, as its not correct for me to go and change the firewall settings simply to get reporting services to operate the way I know it is meant to work. It almost feels as if somehow the reports KNOW that they were deployed with a different data source, and are balking at letting me change that. Why? <frust>
|||Duh, in my post above I couldnt see why changing the data source on the report after deployment didnt work... not too surprising as the mapping between the server name and the IP address (the hosts file) was not set up on the reporting services server the same way it was set up on the server from which I was doing the deployment. Need I say it... duh
Never mind!
Pjos
No comments:
Post a Comment