Is Report Manager a myth?

I've never been able to get to it. I must admit my first few attempts were before I had properly configured Reporting Services. But after two fresh installs, including a fresh OS install (64 bit Vista Ultimate) I still can't get to Report Manager. The closest I've been able to come is this error message:

Error

The report server is not responding. Verify that the report server is running and can be accessed from this computer. Home

The service is running and I'm on my local computer which I have admin rights. I'm stumped.

There may be some special things you need to do to see Report Manager on Windows Vista.

Did you try seeing if the virtual directory was created in IIS?

Can you see other web sites on this machine? It could be a Windows firewall or name resolution issue.

Here is a posting on installing with Vista.

http://www.jameskovacs.com/blog/ReportingServicesOnWindowsVista.aspx

Here is another thread with a similar issue.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=150192&SiteID=1

cheers,

Andrew

|||

Thanks. I'd installed all the IIS componets as per the blog suggestion, I've installed all the SQL Server SP's I can find. I've put both Report Server and Report Manager in the Classic .NET AppPool. The ASP .Net Service Account is "NT Authority\NetworkService". My Windows Service Account is "Local System".

My Log contains the following:

ReportingServicesService!servicecontroller!5!5/8/2007-09:52:25:: i INFO: RPC Server started. Endpoint name ='ReportingServices$MSSQL.3'
ReportingServicesService!servicecontroller!9!5/8/2007-09:52:25:: i INFO: Recycling the service from default domain
ReportingServicesService!library!f!5/8/2007-09:52:25:: i INFO: Catalog SQL Server Edition = Developer
ReportingServicesService!servicecontroller!9!5/8/2007-09:52:26:: i INFO: New app domain started
ReportingServicesService!crypto!f!5/8/2007-09:53:18:: i INFO: Initializing crypto as user: NT AUTHORITY\SYSTEM
ReportingServicesService!crypto!f!5/8/2007-09:53:18:: i INFO: Exporting public key
ReportingServicesService!crypto!f!5/8/2007-09:53:18:: i INFO: Performing sku validation
ReportingServicesService!crypto!f!5/8/2007-09:53:18:: i INFO: Importing existing encryption key
ReportingServicesService!servicecontroller!e!5/8/2007-09:53:18:: i INFO: RPC Server stopped
ReportingServicesService!servicecontroller!e!5/8/2007-09:53:18:: i INFO: Service shutting down.

I don't know where to look to see if a virtual directory was created. IN MSSQL.3 there is a Reporting Services directory but no sub named "Reports".

|||

Doesn't look like a virtual directory issue. Possibly an encryption key issue? Did you run the configuration utility for Reporting Services and initialize it?

Virtual directory should be located in IIS Manager.

cheers,

Andrew

|||

My Encryption Keys has a blue exclaimation point. I've run all the initializations I can find in the RS Config Mgr. I've backed up the keys. There doesn't seem to be any initialization on the Encryption Keys screen.

Thanks.

|||

Did you try RSkeymgmt command?

See this article...

http://www.it-jedi.net/2006/02/how-to-change-any-password-in-mom.html

cheers,

Andrew

|||I'll try that. In the mean time I was running SQL area config reporting services & when I selected Windows Integrated Security I got long error message with the entry Access to the path 'C:\...RSReportServer.config' is denied.

is null in where clause does not work properly

We have a very simple select statement:
select E.COURSE_YEAR, E.COURSE_SESSION, E.COURSE_CODE, E.FLAG
FROM enrollment e
where
e.course_year=2005
and e.course_session=2
AND E.FLAG IS NULL
There were 16743 records returned but more than half of them contain a value
in the FLAG field. What can be happening here? What can I check?
Funny enough (not really), when I take out the "AND E.FLAG IS NULL" clause,
there were 16778 records returned, but when I do "AND E.FLAG IS NOT NULL", I
got 7514 records, which is correct. I'm losing my mind over this.
We are running SQL Server 2000 w/SP3 on W2k3 standard edition.
We ran into a similar problem with a slightly more complex sql statement.
The strange thing is that if we ran the query 20 times we would probably
have the correct data returned to us somewhere between 2 and 4 times.
The .818 patch fixed the issue for us. As always, test the patch on a test
system first.
http://support.microsoft.com/kb/821277
Keith
"Terence Leung" <TerenceLeung@.discussions.microsoft.com> wrote in message
news:E5958FF9-7B60-44D9-BCC0-E5FDF562AE8A@.microsoft.com...
> We have a very simple select statement:
> select E.COURSE_YEAR, E.COURSE_SESSION, E.COURSE_CODE, E.FLAG
> FROM enrollment e
> where
> e.course_year=2005
> and e.course_session=2
> AND E.FLAG IS NULL
> There were 16743 records returned but more than half of them contain a
> value
> in the FLAG field. What can be happening here? What can I check?
> Funny enough (not really), when I take out the "AND E.FLAG IS NULL"
> clause,
> there were 16778 records returned, but when I do "AND E.FLAG IS NOT NULL",
> I
> got 7514 records, which is correct. I'm losing my mind over this.
> We are running SQL Server 2000 w/SP3 on W2k3 standard edition.
|||Thanks for the reply. We haven't tried the patch yet. Luckily the system is
not in production yet and we still have time to play around. We found out
that it is a multi-processor issue - similar to the one documented for SQL
Server 7.0. When we assign SQL Server to use one processor only, the problem
goes away.
"Keith Kratochvil" wrote:

> We ran into a similar problem with a slightly more complex sql statement.
> The strange thing is that if we ran the query 20 times we would probably
> have the correct data returned to us somewhere between 2 and 4 times.
> The .818 patch fixed the issue for us. As always, test the patch on a test
> system first.
> http://support.microsoft.com/kb/821277
> --
> Keith
>
> "Terence Leung" <TerenceLeung@.discussions.microsoft.com> wrote in message
> news:E5958FF9-7B60-44D9-BCC0-E5FDF562AE8A@.microsoft.com...
>
>
|||Just looked around and yes, the security fix you mentioned has that fix. I'll
give it a try next week.
Thanks.
"Keith Kratochvil" wrote:

> We ran into a similar problem with a slightly more complex sql statement.
> The strange thing is that if we ran the query 20 times we would probably
> have the correct data returned to us somewhere between 2 and 4 times.
> The .818 patch fixed the issue for us. As always, test the patch on a test
> system first.
> http://support.microsoft.com/kb/821277
> --
> Keith
>
> "Terence Leung" <TerenceLeung@.discussions.microsoft.com> wrote in message
> news:E5958FF9-7B60-44D9-BCC0-E5FDF562AE8A@.microsoft.com...
>
>