[Anonymous]

Hi Jim,

  What's your QWP and SP version?

Thanks,

[Anonymous]

Hi Jim,

   I created a list of 2,500 items and the chart displays the correct data for all 2,500 records.

I did the same for qSIChartView and same result.

I was using QWP 5.5 and SP2010.

If you could provide your list template (including the data) I'd be happy to test in my env.

Also please check if you have any SharePoint configuration that would limit your list size.

[Anonymous]

Thanks, . We are still at SP2007 and QWP 5.2. I don't know of any list size limitations.

Back when I was working with Quest on the case associated with this, they acknowledged an issue with some of the legend data on the charts but could never reproduce any report total issues like what we had. It has been many months since we were dealing with this so it will take some time for me to dig up the scenario and give you specifics on what we saw. Will do so as soon as I can. Thanks again!

Jim

[Anonymous]

Hi Jim,

  The test I did was quite simple, I created an Excel file with 2500 items (one fiels with a fixed text value and one with number 1) and I imported in SharePoint where I set up qChartView to display the list and count the items. The result was 2500 items as expected.

Try to do something similar and see the result.

I know that we've discussed about upgrading to a more recent version and your IT dept is looking into it.

[Anonymous]

, 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

[Anonymous]

I worked on the issue and it's fixed it in the latest version QWP 5.6 that will be GA this month.

We added a new option in the ezEdit->Configuration->"Case Sensitive Calculation" that allows your to make case sensitive/insensitive operations.

[Anonymous]

Thanks for the update – which issue is fixed, the totalling or the doubling-up of the bars? I assume you mean the totalling, since you suggested that the issue with doubling the bars (H, h, M, m, L, l) was with our data. It is not an issue with case-sensitivity. All our values are uppercase.

– Jim

[Anonymous]

Hi Jim,

  By adding the option to make the calculation case sensite/insensitive your issue is fixed. Both calculations and bars.

Those double bars were because it was making case sensitive calculations (treating M and m as different).

I hope that I brought some light here. If you still have questions please let me know.

I know the issue well since I worked on the case and then on the fix.

[Anonymous]

Wow, I put my foot in my mouth. Sharepoint has a bizarre way of handling the case thing itself. I made my statement above based on the observation that when I use the SP filter option on the Business Case column, it was only showing me values "H", "M", "L" and null. But when I just scroll through the rows, I do see examples of lower-case values.

I even added a filter on my standard view that said "Include where business case = 'm' but do not include where business case = 'M'". It came back with no rows. And yet I see at least one example where Business Case is "m". Sorting doesn't make it any easier to identify those. Obviously that column should have been defined as choice (or lookup) instead of single line of text.

Only by exporting to Excel (and then saving as Excel 95) could I tell that there were lowercase values in there by sorting with case-sensitivity enabled.

I apologize for insisting that it was all uppercase. (Teaches me a lesson how much to trust Sharepoint too.)

Thanks, .

Now I need some ketchup for this plate of crow.

– Jim

[Anonymous]

Are there specific limitations with qChartView web part when it comes to the number of items in the target list?  We are seeing what appears to be a maximum of 2000 items in our chart totals, regardless of the number of items in the list we are charting against.

Neither the Forum nor the help appear to address this question.

Thanks!

Jim

[Anonymous]

Let me tell you that I spent some time to figure out the capital M and lower case m.

I just couldn't see it from the SP OOB view. I exported then I saw the issue.

No need to apologize, is good lesson for us.

Trust more QWP than Sharepoint

We added a valuable fature to our product thanks to you,

[Author]

Posts