Thanks Vince,

But, for example, I wanted to keep it very simple just as a test.  I wanted to make sure there would be no issues with binding the dataset to the tree control.  I actually have 3 levels of data, that come from 3 or more tables, so eventually, It will have a hierarchical display format.  That is the reason i chose the infragistics tree control.  But, my code WAS as follows:

this.UltraWebTree1.Levels[0].ColumnName = "name";

Line 80:             this.UltraWebTree1.DataSource = ds1;
Line 81:             this.UltraWebTree1.Levels[0].ColumnName = "name";
Line 82:             this.UltraWebTree1.DataBind();
Line 83: 
Line 84: 

So, my next step is to bind the tree to either 3 datasets, or one dataset that is the result of a query.  In the examples, there are three different queries added to one dataset.  But, most likely I will have 3 datasets, so I am thinking I would have to convert each dataset to a datatable, then bind it that way?  or what options do I have?  As I would only be returning 3 datasets from three different procedures in the data layer.  I could also make one query with all 3+ tables involved, but that logically wouldn't seem to work based on the examples, as there are three different 'tables' bound to the dataset, then relations are manually set in the dataset, and the relation names of the dataset are passed to the tree control, as well as the 'levels' or 'indexes' in the tree control is set to each 'table' from the dataset.

Thanks.

Relations between DataTable objects are applied at the DataSet level.  All three of your tables will need to thus be part of the same DataSet, and all three must be connected via DataRelation objects, if you want the tree to databind the data rom these three tables in the same hierarchy.  Be sure to set the DataMember property to the name of the table you want to show for the root nodes in the tree.

The other option is to not use data binding at all, and instead to populate the nodes of the tree based on the rows returned from each of the three DataSet objects.  I'm assuming that this isn't a desired approach, of course, given that your original question in this thread was about data binding in the first place.

I've gotten the 3 levels to work.  Of course,  having three datasets to be combined into one required some extra coding, as follows:

DataSet dsmain = new DataSet();

ds2.Tables[0].TableName = "table2";

dsmain.Merge(ds1.Tables["table1"]);

dsmain.Merge(ds3.Tables["table3"]);

Only then, is the data ready to be bound to the tree, along with setting relations, column names, and indexes.

Help has been great here and by Technical support personnel.  I have one other quick question:  My tree is now working fine, and bound 3 levels deep to 3 queries.  I now want to be able to update the tables (that are bound to the tree control) from another button on the form (where the tree control resides), and have the tree data to be updated after the code updates the database, WITHOUT collapsing the tree, preferrably just adding or removing any nodes depending on how the table is updated.  Is there a simple way to do this, or an example?  Thank you.

You would have to programmatically add a DataRelation between your parent DataTable and child DataTable.  Without a DataRelation, WebTree would have no way to determine how items in the two tables are meant to relate to each other.

That's what I was thinking as well.  However,  would I have to hardcode a 'relation' field in the hardcoded parent table to be able to have a relation between the parent and child tables?  As, there is no real relationship between the hardcoded text and the child tables.  I also noticed that there must be a relationship between any tables you want to display as subnodes, otherwise they won't display on the tree.

The simplest option I can think of is to first fetch the data for your child nodes from your database, then programmatically add a DataTable to the resulting DataSet to represent your parent nodes, along with a DataRelation to link your new table to the DataTable you want to represent the first child nodes.  From there, you'd databind the DataSet to WebTree as if all the data had come from the database in the first place.

Ok.  I've scrapped that idea, as it doesn't seem to be that important to the users to have nodes to be updated without re-opening the tree (at least so far.)  My next question is:  I now want to be able to mix and match both hardcoded Nodes and nodes that are from a database.  I'm not so sure that databinding is the way to go now.  For example  First level would be hardcoded and would always be present (so The top level would have two 'hardcoded so to speak' nodes which are "accepted items" and "pending items".  so all subnodes would of course be 'below' these two hardcoded nodes.  But, based on the examples, and docs, it seems that I still can only use one dataset to bind to the tree.  But, having 2 nodes that are not databound above all the rest of the nodes would seem to suggest use of 2 datasets, as I tried one dataset hoping it would just be able to bind to level 1, but of course, it doesn't show up.  Would you have any suggestions?  And, examples would be great.  Thank you again Vince.

This isn't a simple process, and I am not able to find any specific samples.  From a theoretical standpoint, there are at least two possible approaches to do this.

One way is to listen to the change events on your data source, so that you can identify which data row has changed (whether modified, inserted, or deleted).  For insertion, you can find the node in the WebTree that corresponds to the parent data row, create a new node with your new data, and insert this as a child node.  For modification or deletion, you can find the node in the WebTree that corresponds to the data row you changed, and either update or remove that node accordingly.  You'll need some way to uniquely identify your nodes based on information you can get from your underlying data.

Another way is to re-bind the tree to your updated data, but to instead keep track of which nodes were expanded before you bind and to re-expand those nodes afterwards.