So how about an article? Or at the very least a contribution to the code library here? :)

Roger

>Thanks John!
>
>You *can* make dynamic changes to your typed DataSets in code, no problem.
>
>Another benefit to typed DataSets that I neglected to mention is that you get to see your column names in the property sheet when binding data ... don't get this with regular DataSets either.
>
>We've taken it one step further and sub-typed those typed DataSets ... you can add your own custom methods to all your DataSets that way, but we mainly did it because we are accessing data only through SP's and, when using the DataAdapter to Fill a DataSet from a SP, .NET insists on calling the DataTables table, Table1, Table2, etc. (This is not a problem if you are filling the DataSet tables individually through queries ...) IOW, when generating a typed DataSet, we leave the names of the DataTables as table, Table1, Table2, etc ... but in our sub-typed DataSet, we change the names to intelligible names that we use in code. It sounds like a bit of extra work, but it's not bad at all (and we've developed a tool or two to use to make it easy for us to do.)
>
>
>~~Bonnie
>
>
>><<
>>A typed DataSet allows Intellisense to kick in for both your table names and your column names, which you don't get with just a regular DataSet.
>><<
>>
>>You know, I don't think I have ever seen such a clear and concise statement that both makes the case for typed data sets and illustrates the difference between the two types of datasets. Maybe I have been inundated with so much info, I have missed seeing it worded this way.
>>
>>Unless one had to add tables/columns on the fly, I don't know why somebody would not want the data sets to be typed. I have not checked this, but are you precluded from dynamic changes with typed data sets?
>>
>>There was a long, elaborate, and quite frankley overly-complicated in Visual Studio Magazine that discussed typed data sets, but never got to the core of the issue like you did here.
>>
>>Thanks!