A WTF moment with SSRS....

...no, 'WTF' does not stand for 'Windows Transaction Framework,' LOL. I am writing to complain about what I believe is the annoying behavior of SSRS 2005 SP1. Specifically, I am trying to invoke a very simple MS SQL Server 2005 stored procedure as the data source of a report. This stored proc has an input parameter of type bit. The corresponding report parameter is type Boolean. When prompted for an input value when running the report, I enter a 0 or a 1. Much to my dismay, the SSRS IDE raises an error along the lines of '...error encountered when converting string value to Boolean.' For sake of argument, let's say that my stored proc's parameter were of the int type. I would then be prompted for a whole number parameter value, which I would be able to enter without a problem (no string-to-integer conversion error). What does SSRS not like about passing Boolean values to a stored proc that is expecting a bit? (Is the Boolean value converted to 'TRUE' or 'FALSE' under the covers?) Please advise, or I will be forced to spell out WTF....

TIA,

mattyseltz

...OK, the problem was my own stupidity. When prompted (in the SSRS IDE) for a parameter value for the input stored procedure parameter of type bit, I should have typed either 'False' or 'True', not 0 or 1. I think that is counter-intuitive, because one would execute the stored proc in Query Analyzer using a value of 0 or 1. Oh, well....

mattyseltz

|||IF you create parameter with Boolean type it should works either with False/True or 0/1. I have some reports like you describe and I was able to use False/True or 0/1. Anyway, you solve a problem, it's a main thing :)sql

A weird problem of Reporting Service

My company is using SQL 2000, Reporting Service SP2, Server 2003, .NET framework 1.1.

We have an ASP.NET application, working properly on one of our test machine, but when we test on another test machine, it would have the following problem:

When we want to view the PDF or EXCEL report generated by Reporting Services, we get prompted to download an ASPX file. If we choose [Open], it will use Visual Studio.NET to open it. But if we choose [Save], and change the extenstion name, it's actually the correct report file.

That means, the report is generated correctly, but we can't open it.

We have added the Content-Disposition to indicate a correct extension name, but that machine still have this weird problem. Frustrately, it works perfectly on our another machine, even without Content-Disposition.

So, we are thinking probably it's related some file system security configuration. Could anyone give me a little hint about it?

Thank you very much!

Hi, we have the same problem. Did you get anywhere with this?|||are u still looking for answer of it?

that's because the server turns on the http compression, stupid IE doesn't understand it.

one thing to work it around is, turn off the compression for aspx, it might affect too much. If that's a concern, change your report generator file from ASPX to another extension, then that extension file won't have compression on. And you can enable asp.net to handle that new extension, which is only used to generate report.

this just works fine for us

A weird problem of Reporting Service

My company is using SQL 2000, Reporting Service SP2, Server 2003, .NET framework 1.1.

We have an ASP.NET application, working properly on one of our test machine, but when we test on another test machine, it would have the following problem:

When we want to view the PDF or EXCEL report generated by Reporting Services, we get prompted to download an ASPX file. If we choose [Open], it will use Visual Studio.NET to open it. But if we choose [Save], and change the extenstion name, it's actually the correct report file.

That means, the report is generated correctly, but we can't open it.

We have added the Content-Disposition to indicate a correct extension name, but that machine still have this weird problem. Frustrately, it works perfectly on our another machine, even without Content-Disposition.

So, we are thinking probably it's related some file system security configuration. Could anyone give me a little hint about it?

Thank you very much!

Hi, we have the same problem. Did you get anywhere with this?|||are u still looking for answer of it?

that's because the server turns on the http compression, stupid IE doesn't understand it.

one thing to work it around is, turn off the compression for aspx, it might affect too much. If that's a concern, change your report generator file from ASPX to another extension, then that extension file won't have compression on. And you can enable asp.net to handle that new extension, which is only used to generate report.

this just works fine for us

A weird problem of Reporting Service

My company is using SQL 2000, Reporting Service SP2, Server 2003, .NET framework 1.1.

We have an ASP.NET application, working properly on one of our test machine, but when we test on another test machine, it would have the following problem:

When we want to view the PDF or EXCEL report generated by Reporting Services, we get prompted to download an ASPX file. If we choose [Open], it will use Visual Studio.NET to open it. But if we choose [Save], and change the extenstion name, it's actually the correct report file.

That means, the report is generated correctly, but we can't open it.

We have added the Content-Disposition to indicate a correct extension name, but that machine still have this weird problem. Frustrately, it works perfectly on our another machine, even without Content-Disposition.

So, we are thinking probably it's related some file system security configuration. Could anyone give me a little hint about it?

Thank you very much!

Hi, we have the same problem. Did you get anywhere with this?|||are u still looking for answer of it?

that's because the server turns on the http compression, stupid IE doesn't understand it.

one thing to work it around is, turn off the compression for aspx, it might affect too much. If that's a concern, change your report generator file from ASPX to another extension, then that extension file won't have compression on. And you can enable asp.net to handle that new extension, which is only used to generate report.

this just works fine for us
sql