If re-setting the DataSource is the only way, i will have to use that way.

However, I have problem making it work.

Setting again the DataSource to the dataset does not work.

Setting the DataSource to null, then to the dataset, show new band but it has no columns (I see only row markers).

Setting the DataSource to a copy of the dataset works ok. However, I don't want the overhead of creating a copy of the dataset.

This seems like an odd behavior. What are you actually trying to do by switching bands around?

Please see this post http://forums.infragistics.com/forums/p/27022/99450.aspx#99450

As I say in this post, I have 3 levels of data to display, where level2 rows must be displayed horizontally.

Let say that:
level1 shows the Production Lines
level2 shows the Marks of the Production Line
level3 shows the Details of the Mark

So, under a "Production Line" row, i have to display each "Marks" horizontally, and for each "Marks" i have to display its "Details" rows vertically.

The only way I've found to do this is that each "Production Line" rows have a different child datatable created at runtime. This datatable contains a "set of columns" for each "Mark" rows (the column name contains the Mark ID) , and "Detail" rows are "merged" into this child datatable into the corresponding set of columns for the Mark.

I've managed to fill the grid like this at initial load.
Now I have to allow the user to insert and remove "Mark" from a "Production Line", which mean I have to add/remove columns in the child  datatable.

Have you done any testing of this with large sets of data? Is your real application going to need to handle more than a few rows?

Because if so, I don't think this approach is going to work. Maybe I am wrong, but it sounds like you are trying to get the grid to display non-homogenous data by creating a new child band for each parent row. That means that every parent row will have a number of child bands equal to the total number of parent rows. I assume that most of the parent rows will only have child rows in a single child table.

Is that what you are you trying to do? If so, then I think you are probably going to run into some serious performance issues once you get more than a few rows of data. If you have 100 parent rows, that means 100 child bands under EACH parent row. Even though 99 of them won't have any data, they will still exist and I would be surprised if that didn't cause the BindingManager in DotNet to slow down considerably.

I could be wrong, it might be worth testing it out.

If you need to display Non-Homogenous data, then the grid is really not designed for that and you may want to consider using WinTree instead. But the tree does not have summaries or filtering functionality so it's something of a trade-off.

Having said all that, the small sample you posted here should work. I don't know why the grid is not picking up the new band. It seems like the grid is removing the original band "Three", and it even seems to be recognizing the new band and the new rows, but for some reason, it's not picking up the columns for the band correctly.

You really shouldn't have to do anything to get this to work. In rare cases, you might need to call:

this.ultraGrid1.Rows.Refresh(Infragistics.Win.UltraWinGrid.RefreshRow.ReloadData, true);

But that only applies if the data source is not sending notifications to the grid, and in this case it clearly is sending the notifications because it's a DataSet.

So this looks like a bug to me. I'm going to forward this thread over to Infragistics Developer Support so they can check it out.

I did some performance test with 20 top rows, each one with a different child band (which means a total of 21 bands). Each top rows child band had about 20 Marks, which means 80 columns in the band(I have 4 columns of Detail rows to display), and about 10 rows of Detail for each Mark. This represent the maximum data the application will have to handle. The performance was good.

It is true that i'm trying to get the grid to display non-homogenous data under each top rows.
But really, my data IS homogenous, I use this approach (I know it's horrible) only because the grid doesn't allow me to display Mark rows horizontally(on the right of each other) and then display the Detail under it.
What could work I think is to make Mark band as a CardView, but then I would need each cardview to be able to display child rows inside/under it, which the grid doesn't allow.

I would be really happy to know if another Infragistics control would be better than the ultraGrid to display the data in this way. I never used the WinTree. Would it allow me to do this kind of data display more easily ?

Mike Saltzman said:

But What I don't get is... how does this data structure help you achieve that? I can't see how this would make any difference. What do you gain by it?

Please have a look at the second project sample i've sent.

This data structure allows to display each (Mark + its Detail rows) on the right of each other (the Mark name is displayed in the column header).

In the sample, if you try to click on a column header in the second grid, second band, this will select all Detail cells of the Mark.

The Mark and its Detail rows must be seen as a whole, a group. And these groups must be displayed horizontally, under the root band.

canam said:

I use this approach (I know it's horrible) only because the grid doesn't allow me to display Mark rows horizontally(on the right of each other) and then display the Detail under it.
What could work I think is to make Mark band as a CardView, but then I would need each cardview to be able to display child rows inside/under it, which the grid doesn't allow.

You kinda lost me here. I think I understand what you want to do. You have a root band, and then you want the children to display under it in a row, like cards, but you need a child band underneath that, which you can't do, since card bands can't display child rows.

But What I don't get is... how does this data structure help you achieve that? I can't see how this would make any difference. What do you gain by it?

Okay I just looked at your sample project. I assumed the mark detail was one a one to many relationship with product line marks. It sounds like you have quite a conundrum there. I think I'd have to look for an alternative solution for what you are trying to do.

Thanks for the clarification Steve.

But I don't see how this could help, my main problem is to display Mark records in an horizontal fashion.

Moreover, a Mark can have multiple child Detail records, and I cannot really aggregate those values into the Mark, they must be displayed as different rows under the Mark.

For example if you had an orders table and a customer table where Order.CustomerID points to a Customer.CustomerID field. The order table itself does not contain the customer name field which is in the Customers table and you would like to be able to include that information in your grid display without having to create some elaborate mechanism to show that information. Using a data table relation between the two tables you can create an expression field in the Orders table that points to the customer name field in the customers table and it is automatically evaluated and updated if the Orders.CustomerID field is changed. So if you had a data relation called FK_Customer_Orders the expression field for the customer name in the order table would be parent(FK_Customer_Orders).CustomerName. It's almost like having a view in a dataset.

In your case I was just wondering if that would help if you could pull your mark detail information into the product line marks table so you didn't have to worry about that third mark detail band.