I am trying to setup a situation that we use a lot and would want to continue using.

Basically, we often bind an Infragistics Ultragrid to a dataset containing 2 or 3 tables. If I bind to a BO then it looks like I am restricted to only one table as the BO itself can only deal with a single table. Is this correct or have I missed something?

Thanks.

You can do this but you will want to use a BBS (BusinessBindingSource) and treat it like a report entity.  By this I mean that you can create a BBS class that automatically wraps your BO, then you can create a property on the parent that is an instance of the children (or other tables).  You can see an example of how to create this here: http://forum.strataframe.net/FindPost15443.aspx

Finally, another option would be to create a view and still use a single BO if you are not dealing with children items.  If you are dealing with a flat table then just create the query and return all of the desired rows from however many tables that you would like. 

Grids get tricky...even when you are just creating a simple class that implements IBindingList, when you get deeper it gets more complicated.  This is just the nature of grids, but this is something that we do and other developers do on a daily basis...there are just a number of different approaches that you can take.

Just for clarification, does this technique allow multiple tables to be bound to an UltraGrid in a similar format to the attached screenshot which shows a dataset containing three tables?

If so, will the UltraGrid be able to add new records to any of the tables just as it would if the grid was bound to a three table dataset?

Sorry if this is a stupid question but I don't understand the internal workings of the BBS

Thanks

It will...but like anytime you use a grid, things can get more complicated....especially when using bands.  A grid looks for a IBindingList interface implementation to determine how to bind and interact with the data object to which it is being bound.  So the BBS is just a class that implements the IBindingList interface and exposes the BusinessObject to which it wraps as a unique object (what the IBindingList expects) for each row.  If you are going to get very complicated (as using bands get become) it is sometimes easier to create a class heirarchy that helps you do this.  You can use a BBS and create several exposed BBS properties that expose the children records.  So you would create a BBS class that represents each BO in question, then the parent business object (yes BO not BBS) create a custom property that exposes the child BBS object....like this:

Notice that a filter is applied to the child BO when the Orders property was accessed.  This ensures that only the orders that belong to the current record are visible at this point in time. 

This should at least get you going in the right direction.