RESOLVED: Sectioning of List causing Totaling Issues

[adam_mc]

For a relational source:

We have a list report that breaks down Store sales by Region and District.
One of the calculations is to count the number of Stores being reported on so that various % to Chain calculations can be made.
The calculation is: 

• Number of Stores = total (1 for Report)

This works perfectly and gives the required total (say 500 stores).

However, as soon as we add a Section on Region to the list, this calculation now becomes the number of stores in that Region rather than the number of Stores in the Chain.
We need the sectioning as this is a precursor to setting up bursting out the report to each of our Region/District Managers.

How can we keep this as the number of Stores in the Chain?

Also, on a side note, how with a sectioned and bursted report, can you keep Chain/Grand Totals on each page?

Any thoughts will be greatly appreciated.
Thanks in advance,
Adam.

[Lynn]

I believe that sectioning will create a master-detail relationship which means separate queries are being fired and the scope "for report" is relative to the query. Try grouping instead of sectioning. You can create a group header to place the grouped element above the details to match the appearance one gets by sectioning. I generally avoid sectioning in favor of grouping.

[adam_mc]

Thanks Lynn...

We've tried that too, but when we burst the report it seems to do the same thing as well.

However, we were able to resolve it by creating a duplicate query and creating a list at the "All Stores" level and place that in the Page Header.
In that way, the Chain Totals appear at the top of every page.

Then, we set the burst options on the Region/District Level query and "hey presto" the Chain Totals are at the top of every page and each Region/District gets its own detail data page in the Page Body.

I understand that this is not the most elegant solution as we are clearly doing the same query twice (but, at least, it is not an overly demanding one) - But, it works!

Thanks again,
Adam