Use Typed or Untyped dataset?

[jerry_hokh]

hi guys,
normally i have one typed dataset for each table in my database, but what if i need retrieve data from 2 tables then what should i do:

1) create an untyped dataset represent 2 tables on database
2) add more column from table2 to table1's dataset
3) make another separate typed dataset represent 2 tables

Which is the best way to do? if none of them is best , pls suggest.

Thanks a lot.

Jerry

 

[cjard]

i'm curious to know why you would need to? normally you might create a DataRelation between the two tables to indicate how the records are to be linked.. and then vb knows how to relate them.

what happens in a practical application is you will have a form that shows info from both tables, like customers and orders (one customer might have 3 orders)

so you'd put text boxes etc to show the customer details, and then you'd put a grid (for example) to show the orders. the data bindings for the customer part would be to a bindingsource that is bound to the datatable for customer.. but here's the kicker

the data source of the orders grid would be pointing to a binding source that itself uses the *relation* as a datasource


then, when you set the record youre viewing for the customer (using a binding navigator) the orders will update to show only orders for that customer

yoiu can edit each independently and save them back to the database from whence they came.. there's no specific need to join the 2 tables into 1..

 

[cjard]

another way (what i do at the minute) to reduce overhead of processing, is to do the joins yourself in code..


taking the customers and orders analogy again, make 2 separate dtatatables and adapters, write fill methods by id for both, then fill the customers data table, then use the info in the customer table to fill the orders table.

suppose we wanted to look up customer 123 and he has orders 234 345 and 456. in the orders table will be a column saying customer ID.. i.e. which customer this order belongs to.. so we fill customers datatable by id 123, and we do the same for the orders.. 2 typed datasets containing the data necessary

of course, if we want to look up a range of customers, say 100 - 150, then we can write a separate query on the table adapters to fill by id greater than x and less than y. we then fill our datatables with these results, and because our datatables now contain multiple entries for multiple cutomers we use the datarelation approach above to have vb manage the data on show


i should have made it clear before that if you have customers and orders datatables, and a datarelation between them, it's still nothing to do witht he database. i was very confused for a long time, thinking "i have made 2 dtables, and i made a data relation, and i filled the customer table with customer 123.. why have his orders not showed up?"
eventually i realised that the records for the orders had to be loaded into the orders dt manually.. i thought vb would do it automatically, but of course, it cannot!
so, the datarelation exists to allow vb to manipulate data in the tables... you must still load cutomers 100 - 150 into the cutomers datatable, and all the relevant orders for all the customers 100 - 150 into the orders.. but having the data relation in there will keep things in check after that!

 

[jerry_hokh]

Thx for ur respond.it's helpful.

by the way, i would like to know when you have your Customer dt and Orders dt filled. How could they be bound to a datagrid? Do i need to have another datatable to represent Customer dt and Order dt?if yes, what is the style of the dt, typed or untyped?

thanks inadvance....

 

[cjard]

your question somewhat confuses me. essentially i think youre asking:

"Once i have a datatable, how do i bind it to a grid? Do i create another datatable to represent a datatable?"
Its the second bit i dont understand - you have a datatable that is.. well.. a datatable. You wouldnt need to make another datatable to represent something that is already a datatable? You can bind a datatable directly to a grid with DataGridView1.DataSource = myFilledDataTable but there are betters ways..


in .net2 the you do:



Create an instance of the DT
Create a BindingSource (BS)
Bind the DT to the BS
Bind the BS to the DAtaGridView



The IDE will do a lot of this for you automatically, if you read the walkthroughs on how to arrange data sources in your app. Once you have a DataSet designed in the IDE< the data sources window of the IDE should show some things. These things can be drag/droppped onto a standard windows form. Have a browse through the tutorials here:

http://msdn2.microsoft.com/en-US/library/fxsa23t6(VS.80).aspx

 

[jmcilhinney]

If you only have one data source then you should only have one typed DataSet type in your project. You would then create an instance of that DataSet in each form or wherever else one is needed. It would be a very, very rare thing that you would need two DataSet instances in the same place. Having a different DataSet for each DataTable is like having a different database for each table: inefficient, pointless and counter-productive.

 

[cjard]

I currently have a project where there are 3 typed datasets in existence - one contains all the "data" tables, data in these tables is filled as needed - things like customer address etc.
ANother dataset contains all the lookup tables - stuff like people's salutations (Mr/Mrs/Dr) and their ID values. I did this so i can instantiate it once, globally, because these things dont tend to change very often. COmbo boxes will be bound to them, and the lookup table dataset instance can be re-used rather than instantiated and filled (which i find a little slow)

The third dataset contains "ghost" tables - tables that arent actually in the database, but are filled by a query that combines various informations from database tables. Essentially it's a dataset for views.

I could have had it all in one dataset, but from a management point of view it seemed like a bit of a headache when i tried, and every form would make its own instance of the dataset, and fill all the lookup tables etc etc..


I do support Mr McIlhinney's point though, and in theory i could create one instance of a dataset globally and assign, in code, all the data bindings. I chose the more visual route for the most part, and though im still struggling with some things, it's getting easier

 

[jmcilhinney]

There are always many ways to do the same thing. Having the separate DataSet for static tables is actually not a bad idea, although some would frown on a global DataSet. I'd be inclined to combine the other two however, but to each their own. Logical segregation is not such a bad thing.