, if you can, go to the Quest Case Management and look at the attachments on case 912362. I went back to that example and refreshed my memory on the behavior. There are two oddities with 5.2, and I think if you read the case history, you will find where I reproduced the issue with later Quest versions (but this was all a few months back).
Using the data in the Case attachments, do a qChartView configured as follows (some of this may be spelled out in the Case; I cannot recall). In my test list, I had done something similar to what you described; what I did though was to create a poorly-named column called "hundred" and assigned a fixed value of 10 (not 100, just 10) to every item. That way I knew it was doing computations, but the math was easy to confirm.
So by charting against the 'hundred' column, your totals should equal the number of records times 10.
On the Display tab:
Chart Type: Column2D
Configuration XML:
<Configuration>
<Series>
<Items FieldName="hundred" AggregateFunction="Sum" ChartSeriesType="COLUMN" SeriesName="Widgets" ShowValues="true" />
</Series>
<XAxis FieldName="Business Criticality" SortFieldName="Business Criticality" SortFieldOrder="ASC" />
<YAxis />
</Configuration>
I built an out-of-the-box SP view that grouped on the Business Criticality field. This is the field that is used to define the columns of the 2DColumn chart. Then I would apply a filter on the chart, and the same filter on the view, and compare the results.
I started by filtering on the ID column, and picking up a small subset of items by just including those whose ID was very small, say less than 200. Then I progressively increase the filter limit so that the chart and the view show more and more data.
It goes well for quite a while. Then one of two things goes wrong:
Instead of seeing three columns for the three possibly Business Criticality values of H, M, L, the chart changes to begin showing double columns for each criticality. So the chart shows a total of six columns, with a legend of H, h, M, m, L, l. When this issue first manifests itself, the actual subtotal represented is "correct" – the value for H and for h both get charted with the correct value for the Business Criticality of "H". Now I say "correct" in quotes because obviously the chart should not have both an "H" column and an "h" column, but just one column for High called "H". And when the number of rows being reported on is small, that is indeed what it does.
But once the number of rows getting reported on gets high enough, the chart gets corrupted somehow and repeats itself. If you increase the row count somewhat slowly (but using progressively larger upper limits for ID), you will see this problem get progressively worse. Specifically what I saw was:
1. for values of ID less than some limit X, it worked correctly, giving me "H", "M" and "L", with the correct subtotals for each.
2. for values of ID from X up to Y, it began going bad, and gave me "H", "h", "L", "l", and "M". In other words, the lower-case "m" column didn't show up right away. However, the sub-totals were "correct" – not perfect, since the duplication had started, but correct within a particular criticality value.
3. for values of ID from Y up to Z, it changes to the full duplication pattern of "H", "h", "L", "l", "M" and "m". Again, the subtotals were correct.
4. With no filter at all on the view or chart, I not only get the duplication pattern, but the subtotals are garbage – still integer multiples of 10, but inaccurate.
If you end up not being able to reproduce, I will rebuild my zip file of test data and make it available to you. It has been so long since I created the initial set that I can't say for certain that I didn't miss something.
Thanks for taking a look into this!
– Jim