Hello Group,
our company had a database on SQL Server 2000 Standard as the source for a
Report Server 2000 Standard. Well, the source databases had to be moved to a
brand new server. As it happened, the SQL Server 2000 on the new server is
Enterprise. Now, the report server will not work. We changed the connection
strings for the reports to point to the new server but no good. We just keep
getting "server not trusted".
Does the type of database server matter to the report server?
RichFirst, I assume that it is just the data that is an issue. Not the
reportserver database itself (where Report server keeps its metadata/object
caching).
My guess is that something else is going on with regards to the security. If
you are using integrated security there might be some issue with RS server
passing on credentials to
What I prefer to do is to have a read only SQL login. I use that for
credentials. I just use the windows domain login to determine who gets to
run what report.
It does not matter in the least where the data is coming from. I report off
of SQL Server standard, SQL Server Enterprise, Sybase, In-SQL (a real time
control historian).
Now, if you are not even having Report Manager come up (i.e. you never even
get where you can select the report to run) then it sounds like RS database
was moved. Again, you have a configuration/security problem going on.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Rich" <Rich@.discussions.microsoft.com> wrote in message
news:E44CB1AD-A386-40E2-BBE6-F1BB1872F817@.microsoft.com...
> Hello Group,
> our company had a database on SQL Server 2000 Standard as the source for a
> Report Server 2000 Standard. Well, the source databases had to be moved
> to a
> brand new server. As it happened, the SQL Server 2000 on the new server
> is
> Enterprise. Now, the report server will not work. We changed the
> connection
> strings for the reports to point to the new server but no good. We just
> keep
> getting "server not trusted".
> Does the type of database server matter to the report server?
> Rich|||Hello Bruce,
thanks...the Report Manger comes up just fine. It displays the folders and
reports and user just like always. I thought that if I changed the
Connection String in the Report Manager, this would be enough. I need to
come up with a stradigy as to how to narrow down the location of the problem.
Rich
"Bruce L-C [MVP]" wrote:
> First, I assume that it is just the data that is an issue. Not the
> reportserver database itself (where Report server keeps its metadata/object
> caching).
> My guess is that something else is going on with regards to the security. If
> you are using integrated security there might be some issue with RS server
> passing on credentials to
> What I prefer to do is to have a read only SQL login. I use that for
> credentials. I just use the windows domain login to determine who gets to
> run what report.
> It does not matter in the least where the data is coming from. I report off
> of SQL Server standard, SQL Server Enterprise, Sybase, In-SQL (a real time
> control historian).
> Now, if you are not even having Report Manager come up (i.e. you never even
> get where you can select the report to run) then it sounds like RS database
> was moved. Again, you have a configuration/security problem going on.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Rich" <Rich@.discussions.microsoft.com> wrote in message
> news:E44CB1AD-A386-40E2-BBE6-F1BB1872F817@.microsoft.com...
> > Hello Group,
> >
> > our company had a database on SQL Server 2000 Standard as the source for a
> > Report Server 2000 Standard. Well, the source databases had to be moved
> > to a
> > brand new server. As it happened, the SQL Server 2000 on the new server
> > is
> > Enterprise. Now, the report server will not work. We changed the
> > connection
> > strings for the reports to point to the new server but no good. We just
> > keep
> > getting "server not trusted".
> >
> > Does the type of database server matter to the report server?
> >
> > Rich
>
>sql
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment