Sunday, March 25, 2012

Datasets in report header/footer - A Summary of the issue

I know there are already a few threads on this topic but I wanted to create another one - and directly ask - how could this limitation possibly exists - and even more important - why is it still a problem in 2005?

I want to summarize a few of the solutions that have been listed here and elseware online. We've tried them all and they all have some kind of problem:

1) Create hidden field(s) and then reference that field from the header: Doesn't work on any pages where the field isn't printed. Header value will be blank in this case.

2) Create hidden column(s) in the data table and reference that from the header: Works, but again, if the table is showing on every page, the value will be blank. i.e. - if you have two or more tables stacked, you would have to add the columns to every one. A very sloppy and not practical solution.

3) Do it with custom code: I've seen this approach recomended but have never actually seen someone provide a working example. From what I understand, custom code can't access the datasets (I'm using 2000 - maybe 2005 is different here?)

4) Use a queried parameter to hold the value- then reference that in the header: This seems to be the best contender so far. It seems to work sometimes, but on several machines here, the report designer goes into some kind of infinite loop and crashes once the queried parameter is added.

If anyone has any other approaches that I'm not aware of, or has another idea, please post it here. Microsoft - this is a huge problem for many people. Is there any chance of a fix for this any time soon?

Thank you.

~H

did you find a solution ?

|||I am very interested in a solution, too.

Although I have found a 5th option, which works quite well for my scenario - nevertheless I don't consider it being very elegant (at least with "allow null values" enabled).

5) Use "Available values: From query"

All

report parameters are hidden and passed via the URL. The parameter

value is an ID, but in the page header my customer would like to see

the corresponding description.

I have have defined the available values to come from a query and specified the value and label fields. Now I can access the parameter value in the page header like e.g.

Parameters!ProcessId.Label

There's one drawback: if you're using parameters having "allow null value" enabled this version gives you an error when openen the report having passed NULL for the parameter (I have to translate the message from german to english):

The process ID parameter value is missing.


This problem can be solved, but I consider it being a quirk. Just use the following SQL for your data set:

select ProcessId, Desc from Processes
union
select ProcessId=NULL, Desc=NULL from Processes


I'm also interested in sharing other (more elegant) approaches.

Thanx for listening and kind regards,
Gerald


|||I am very interested in a solution, too.

Although I have found a 5th option, which works quite well for my scenario - nevertheless I don't consider it being very elegant (at least with "allow null values" enabled).

5) Use "Available values: From query"

All

report parameters are hidden and passed via the URL. The parameter

value is an ID, but in the page header my customer would like to see

the corresponding description.

I have have defined the available values to come from a query and specified the value and label fields. Now I can access the parameter value in the page header like e.g.

Parameters!ProcessId.Label

There's one drawback: if you're using parameters having "allow null value" enabled this version gives you an error when openen the report having passed NULL for the parameter (I have to translate the message from german to english):

The process ID parameter value is missing.


This problem can be solved, but I consider it being a quirk. Just use the following SQL for your data set:

select ProcessId, Desc from Processes
union
select ProcessId=NULL, Desc=NULL from Processes


I'm also interested in sharing other (more elegant) approaches.

Thanx for listening and kind regards,
Gerald


sql