I created a report with a section header to create identical lists for different values of one field. I find this a more elegant solution than using a master-detail relation with the page. This works fine so far.
Now I add some rows from a different star using a union. When I switch the query for either the inner list or the section list, the report starts to behave differently, showing more rows, etc. This feels strange to me, since basically I just add more rows to the same dataset. Who knows what I am overlooking? Or is there some hidden or hard to find setting related to sections that has a relation to the query name?
Hi,
Did you check the data of the outer list and inner list by hardcoding the filters to see if you are getting the same data in the tabular data after switching the queries? As you said that you are using union and union brings more rows. Please check the data of both lists in the tabular form and let us know if it is not matching with the actual lists data.
Good luck
New guy
I think I have to be more specific about what is happening. I have 2 versions of the same report. One page has a total of all values of a certain category (cost centre) in one list. The second page has the same list with sections per value of that category (cost centre).
It already goes wrong when I connect the new union query to the first list with the total. In the list there is an aggregation on other categories (brand family). When I select e.g. 3 values of the cost centre category, I see (max) 3 rows of each brand family instead of one. So it looks more of a grouping issue. The thing is that all data items in the union are set to automatic. So I would think the grouping would work correctly.
How should I alter the grouping to get the right list again?
Anybody? I have D. Eadline breathing heavily down my neck...
I solved it myself. Apparently it's enough to change the aggregation of all measure data items from automatic to total. I wonder why Cognos chooses another option than total for the numbers with automatic, but it's fixed now.