I'm working with the ASPxPivotGrid and I've noticed that if I have multiple arguments or series, and then expand some but leave others rolled up, CreateSummaryDataSource will only return the fully expanded ones.
Please see the attached screenshot for an example. The upper part of the screenshot is a portion of my pivot grid, and the lower part is simply a DataGrid which shows everything that was returned from the CreateSummaryDataSource call to the pivot grid.
The data source in the example is only being populated with the fully expanded rows (those corresponding to 1/5/2009 and 1/19/2009). I would expect that it would show all rows, and it would simply fill in the Priority column with "All" (or blank, or null, or whatever) for the 1/12/2009, 1/26/2009, and 2/2/2009 rows.
I tried binding the data grid directly to the pivot grid, and when I do that I get the output which I would expect (I see a row in the data grid for every row in the pivot grid, and the expanded rows have the Priority argument piped on to the end of the Argument column). However, when I tried binding a chart to the pivot grid, I observed that it was only finding the fully expanded rows, i.e., the same ones that I see when I call CreateSummaryDataSource.
Am I missing something obvious?
Steps to Reproduce:
In Visual Studio, all you have to do is:
- Create a new website project.
- Drag an ASPxPivotGrid and link it up to an OLAP cube that has at least 2 dimensions and 1 measure.
- Go to the Fields property editor for the grid. Retrieve the fields from the linked cube and place at least 2 dimensions in the RowArea, and make sure there's at least 1 item in the DataArea. Remove anything beyond that, to provide the simplest example.
- Add an ASPxGridView, for easy visualization of the data we're about to extract. Turn off paging in this grid.
- Add a button. In the event handler, add some code which calls CreateSummaryDataSource on the pivot grid, and then sets the GridView datasource to be the newly created source. e.g.,
PivotSummaryDataSource ds = ASPxPivotGrid1.CreateSummaryDataSource();
ASPxGridView1.DataSource = ds;
ASPxGridView1.DataBind(); - Run your project. Don't expand anything on the PivotGrid, just click the button. Note that the number of rows in your PivotGrid is identical to the number of rows in the GridView. Also note that for any dimensions which are collapsed in the RowArea, you have a column for those, but the column is always empty because you are looking at an aggregation of that data.
- Now expand a couple of rows in the PivotGrid, but leave several fully collapsed. Click the button again, and note that now your GridView is populated _only_ with the fully expanded rows. This seems like bad behavior to me…I should still see all of the rows which are collapsed, and they should simply have blank entries for any columns which are not visible due to being aggregated into a higher level dimension.
Actual Results:
see the attached screenshot
Hi,
I'm not sure how to recreate this behavior. Could you please provide a sample to reproduce this issue? It looks like an inconsistent behavior in the ASPxPivotGrid.
Thank you, Marina
Well, I can't provide a sample project without building a new offline cube filled with dummy data and linking it up, but the steps are fairly simple to reproduce, as long as you have some kind of OLAP data source over on your end, which I imagine you do.
In Visual Studio, all you have to do is:
PivotSummaryDataSource ds = ASPxPivotGrid1.CreateSummaryDataSource();
ASPxGridView1.DataSource = ds;
ASPxGridView1.DataBind();
For comparison, if you create an additional GridView and set the datasource to be the your PivotGrid (rather than the SummaryDataSource created from it), you'll see that you can expand and collapse to your heart's content, and all the data can still be seen. Rows which have expanded members simply get additional elements piped on to the end of the Arguments column.
Does that clear things up?
Hi,
Thank you for your detail steps. We are researching this issue, and will post an answer ASAP.
Thank you, Marina
Works fine in 8.3.5, thank you!