>>The respective insert, update, delete, and select logic belongs on the data tier, specifically, the data server.<

Yep, and for the most part we respect that ... except that we don't have a huge SP for transactionally updating parent/child tables. It's easier to handle the whole "what table gets updated when" aspect of updating this sort of data in C# code, rather than in T-SQL in a SP. So, our DataAccess layer handles setting transactions on, then calling the individual table's update SP for each table in the parent/child DataSet, then either committing or rolling back the transaction.

~~Bonnie

>>
>I dunno ... we seem to be ok with it. We are accessing our SQL Server only through SP's, so as far as the Command Builder goes, we're not using it ...
><
>
>Good move. The command builder ends up building a mess of client-side sql that is a PITA to manage. The respective insert, update, delete, and select logic belongs on the data tier, specifically, the data server.
>
><
>we roll our own ... and it's not that difficult. Look into it. I think limiting DataSets to only one table is *not* the way to go. I am also a big advocate of using typed DataSets.
><
>
>I agree, limiting datasets to one table defeats to power and purpose of a dataset.
>
>
>>~~Bonnie
>>
>>
>>>>We have DataSets that contain many tables (a parent and many children).
>>>
>>>I had heard to specifically stay away from that model and limit datasets to one table - I believe primarily because of diffculty with data adapter or perhaps the command builder?