I am trying to achieve something like this. I have a POSITION list and bunch INSTRUMENT lists. Every POSITION has a corresponding INSTRUMENT ID and INSTRUMENT Type. INSTRUMENT Type identifies the type of the instrument and corresponding INSTRUMENT List. POSITION is my primary list currently bound to my grid.
I need to have my UltraGrid bound to both of these lists. So, every row in the list will contain POSITION details as well as the INSTRUMENT details associated with the position. I need to append INSTRUMENT columns to the grid if user wishes to view the instrument associated with the position.
Is there any way to have a grid bound to multiple data sources at the same time. I would have made a combined object. But I need to have flexibility over the datasources as they update in real time.
Thanks!
Hi,
The grid can only have one data source.
I'm not really clear on what you need to do here, but it seems like you should be able to acheive what you want in a number of ways:
1) You could use a DataSet with multiple tables and a relation to create a hierarchy in the grid.
2) You could use SQL to return a single table that contains the join of information you need.
3) You could add unbound columns to the grid and populate those columns in the InitializeRow event.
I do not really want a parent child relationship as every position is associated with only 1 instrument.
That is the ultimate solution which I might implement. But, I wanted to have POSITION and INSTRUMENT as separate lists so that I can use these lists for other components of my application as well.
Just needed an advise on this: As I have around 70-90 properties per Instrument and 21 properties for Position, will it make the interface sluggish? My screen/form is expected to show around 100-400 positions at a time.
I also thought of preparing the complex object when my data is being loaded from the data provider. B ut, I am quite reluctant to have duplicate data on the client side. This might be one of the ultimate solutions thought if I am not able to implement one of the solutions you mentioned!
Thanks for your help Mike!
The major difference between option 2 and option 3 is that with option 2, you retrieve all of the information at once and build a structure with all of the data in it up front, whereas with option 3, you go out and grab the related information from each row as that row is loaded into the grid.
So the cost of retrieving the information is the same, it's just a question of when you do it and how often.
If you are concerned about performance, then Option 2 is probably better. There might be a small delay in the loading of your application while it retrieves the data, but after that, everything will run smoothly.
In fact, Option 3 will behave pretty much the same way, by default, since the grid will fire InitializeRow for all of the root-level rows as soon as it's bound, anyway.
But, you do have the option of setting the LoadStyle on the grid to OnDemand so that it will only load rows as-needed and thus Option 3 might save you some loading time at the cost of having to load the data as the application is running.
Setting a Value in a grid cell is not a particularly expensive operation, but it's hard to say if this will make your application sluggish. I don't know what kind of relation there is between the two tables or how efficient it is for you to retrieve the instrument data for any given position.
If you are using a DataSet with two tables and a relation, then I can tell you that the DataSet is not very efficient at retrieving child data.
Frankly, if the data is 1-to-1, then it seems a bit off to even have it in two tables. I suppose you probably have a good reason for doing it that way, but it's an unusual case, and if it were me, I might explore the possibility of keeping a single table. If that's no possible, then I'd probably go with joining the tables wither via a SQL query or in code.