parameter properties in report manager - "Has Default"

ok I've designed a report template that uses cascading paramters based
on several sp's. The user selects a value for the first parameter and
that value is passed to the sp that populates the second parameter
list. The value selected for the second param is used to populate the
third param list etc...
I want the first parameter to be required and the other 3 to be
optional - the report should still run if they are not selected. RS
BOL told me to go into the Report manager, select "Properties"
then"Parameters" and then select the "Has Default" check box for the
three optional paramters. This in turn enables the "Null" checkbox, so
I checked that box so null will be the default value passed if these
parameters are not selected.
By all accounts this should allow the report to run with only the first
parameter selected, but when run from Report Manager it still keeps
prompting the user to enter values for the 3 other optional parameters.
Any ideas? help?Never mind! found a workaround...

Parallelism Question

If SQL Server is designed for multi processor systems, how can running
a query in parallel make such a dramatic difference to performance ?

We have a reasonably simple query which brings in data from a few none
complex views. If we run it on our 2x2.4Ghz Xeon server it takes 6
minutes plus to run. If we run this on the same server with
OPTION(MAXDOP 1) at the end of the same query it takes less than a
second.

Examining the execution plan, the only difference I have been able to
see is that parallelism is taking up 96% of the run time when using
two processors. This drops when using the one so a sort takes up the
vast majority of the time for the query to run.

OK, so running in parallel should mean that it's run in various parts
and then 'joined up' later for performance gains, but how can it get
it so wrong (timewise) ?

If this is the case, will I see a significant difference changing our
server to use a single processor, which seems completely the wrong
approach (or should I do this on each query in each app - eek) ?

Do we have a problem that we don't know about that causes it to take
this long ?

What can we do ? Ideally, using both processors would seem to be
preferrable.We've changed the server to use a single processor at the moment and
the report that my query is based on works almost instantly. We're
waiting to see what effect this has for other users, but so far,
no-one has complained.

Are we wasting a second processor ?|||"Ryan" <ryanofford@.hotmail.com> wrote in message
news:7802b79d.0312160816.68d60164@.posting.google.c om...
> We've changed the server to use a single processor at the moment and
> the report that my query is based on works almost instantly. We're
> waiting to see what effect this has for other users, but so far,
> no-one has complained.
> Are we wasting a second processor ?

No. There are definitely times it can help.

You may want to open a ticket with MS. In general, when the query optimizer
finds such a poor optimization they consider it a bug. (If you can, review
Kalen Delaney's article in this month's SQL Server Magazine.)

Paging issue on conditionally set second table visibility

Hi. I am having a problem with a 2005 report that has two tables and is designed thru visual studio. The second table is set to page break before printing and also to repeater headers on new pages. It works fine just like that. However, if I place a condition on the visibilty of the table based on an input report parameter it does not page break before rendering the table. In fact it does not page break at all leaving me with an extremely long last page. The visiblity parameter does properly toggle. This is all occurring when rendering the report to the screen using the windows reportviewer. When I export to PDF it looks fine.

Any help would be great.

This is currently by design - when the visibility property is expression-based, the page break is ignored. We are considering changing this behavior in the next release.|||

Thanks for the reply Fang.

I do hope you consider chaninging it. I can understand ignoring the page break when visibility is false but I am not sure why one would want to ignore it when visibility is true. Also, the way it is now the rendered report is not consistent between the screen and PDF.

|||Thanks so much for posting your problem. We are converting from crystal to reporting services and have been experiencing this same issue and were very puzzled. This "by design feature" is making a lot of our reports look very inconsistent with pagination between the viewer and printer or pdf. Reminds me of an early crystal reports viewer problem, which they fixed a long time ago...|||Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...|||

Spivey wrote:

Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...

what does next release meant , is it fixed in sp2 2005.

|||

No, its not fixed, but I figured out a solution. The next release will coincide with the next release of SQL Server - 2008 sometime.

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

|||

What is wrong with the people at Microsoft? Just when you think they have done something right, they screw up something like this!

WHY WOULD ANYONE WANT TO IGNORE THE PAGE BREAK IF IT IS VISIBLE?!

Ugh!!!!!!!!!!!!!!!!!!!!!!!!!

Paging issue on conditionally set second table visibility

Hi. I am having a problem with a 2005 report that has two tables and is designed thru visual studio. The second table is set to page break before printing and also to repeater headers on new pages. It works fine just like that. However, if I place a condition on the visibilty of the table based on an input report parameter it does not page break before rendering the table. In fact it does not page break at all leaving me with an extremely long last page. The visiblity parameter does properly toggle. This is all occurring when rendering the report to the screen using the windows reportviewer. When I export to PDF it looks fine.

Any help would be great.

This is currently by design - when the visibility property is expression-based, the page break is ignored. We are considering changing this behavior in the next release.|||

Thanks for the reply Fang.

I do hope you consider chaninging it. I can understand ignoring the page break when visibility is false but I am not sure why one would want to ignore it when visibility is true. Also, the way it is now the rendered report is not consistent between the screen and PDF.

|||Thanks so much for posting your problem. We are converting from crystal to reporting services and have been experiencing this same issue and were very puzzled. This "by design feature" is making a lot of our reports look very inconsistent with pagination between the viewer and printer or pdf. Reminds me of an early crystal reports viewer problem, which they fixed a long time ago...|||Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...|||

Spivey wrote:

Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...

what does next release meant , is it fixed in sp2 2005.

|||

No, its not fixed, but I figured out a solution. The next release will coincide with the next release of SQL Server - 2008 sometime.

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

|||

What is wrong with the people at Microsoft? Just when you think they have done something right, they screw up something like this!

WHY WOULD ANYONE WANT TO IGNORE THE PAGE BREAK IF IT IS VISIBLE?!

Ugh!!!!!!!!!!!!!!!!!!!!!!!!!

Paging issue on conditionally set second table visibility

Hi. I am having a problem with a 2005 report that has two tables and is designed thru visual studio. The second table is set to page break before printing and also to repeater headers on new pages. It works fine just like that. However, if I place a condition on the visibilty of the table based on an input report parameter it does not page break before rendering the table. In fact it does not page break at all leaving me with an extremely long last page. The visiblity parameter does properly toggle. This is all occurring when rendering the report to the screen using the windows reportviewer. When I export to PDF it looks fine.

Any help would be great.

This is currently by design - when the visibility property is expression-based, the page break is ignored. We are considering changing this behavior in the next release.|||

Thanks for the reply Fang.

I do hope you consider chaninging it. I can understand ignoring the page break when visibility is false but I am not sure why one would want to ignore it when visibility is true. Also, the way it is now the rendered report is not consistent between the screen and PDF.

|||Thanks so much for posting your problem. We are converting from crystal to reporting services and have been experiencing this same issue and were very puzzled. This "by design feature" is making a lot of our reports look very inconsistent with pagination between the viewer and printer or pdf. Reminds me of an early crystal reports viewer problem, which they fixed a long time ago...|||Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...|||

Spivey wrote:

Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...

what does next release meant , is it fixed in sp2 2005.

|||

No, its not fixed, but I figured out a solution. The next release will coincide with the next release of SQL Server - 2008 sometime.

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

|||

What is wrong with the people at Microsoft? Just when you think they have done something right, they screw up something like this!

WHY WOULD ANYONE WANT TO IGNORE THE PAGE BREAK IF IT IS VISIBLE?!

Ugh!!!!!!!!!!!!!!!!!!!!!!!!!

Paging issue on conditionally set second table visibility

Hi. I am having a problem with a 2005 report that has two tables and is designed thru visual studio. The second table is set to page break before printing and also to repeater headers on new pages. It works fine just like that. However, if I place a condition on the visibilty of the table based on an input report parameter it does not page break before rendering the table. In fact it does not page break at all leaving me with an extremely long last page. The visiblity parameter does properly toggle. This is all occurring when rendering the report to the screen using the windows reportviewer. When I export to PDF it looks fine.

Any help would be great.

This is currently by design - when the visibility property is expression-based, the page break is ignored. We are considering changing this behavior in the next release.|||

Thanks for the reply Fang.

I do hope you consider chaninging it. I can understand ignoring the page break when visibility is false but I am not sure why one would want to ignore it when visibility is true. Also, the way it is now the rendered report is not consistent between the screen and PDF.

|||Thanks so much for posting your problem. We are converting from crystal to reporting services and have been experiencing this same issue and were very puzzled. This "by design feature" is making a lot of our reports look very inconsistent with pagination between the viewer and printer or pdf. Reminds me of an early crystal reports viewer problem, which they fixed a long time ago...|||Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...|||

Spivey wrote:

Yeah, I would consider really hard changing that! The master-detail report I spent 2 days on is completely useless because it loads entirely on one page and takes forever. Now I have to rewrite it in Crystal...

what does next release meant , is it fixed in sp2 2005.

|||

No, its not fixed, but I figured out a solution. The next release will coincide with the next release of SQL Server - 2008 sometime.

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

|||

What is wrong with the people at Microsoft? Just when you think they have done something right, they screw up something like this!

WHY WOULD ANYONE WANT TO IGNORE THE PAGE BREAK IF IT IS VISIBLE?!

Ugh!!!!!!!!!!!!!!!!!!!!!!!!!