>>But I have worked with untyped datasets and I really thought it was a lot of work and was tedious. We've got tables with 100 or more fields. To do an update with a SQL update statement or a stored procedured each of those fields would need to be coded up as a parameter. That would be very tedious.

Yes, it is for sure and extremely error prone.
Check around tho, and you'll find some slick tools that make that a cinch.
Naomi Nosonovski pointed me at a tool that generates the stored procedures from the SQL table. That tool has saved me days, if not weeks, of work.
It generates perfect insert and update stored procedures in seconds -

thank you, thank you Naomi!!!
.
google sp gen and you'll find it and some others like it


Regarding C# generating the parameters and the data to feed to the parameters, it also does that, but I wanted some specific functionality, so after some thought I was able to write a generalized module that does that automatically,given the datatable and the SP name.
It's really not rocket science once you put your mind to it.

I'm using it constantly and it works like a charm. we write the code to update or insert from a datatable in less that 5 minutes and it's foolproof, irrespective of the number of columns in the table.. data types, etc.
.
If you look under the hood of most of the frameworks, that's exactly what they do. Doing it on your own lets you do little things that are unique to your app, like handling identity coluimns the way you want, etc.

Check out Bonnie's blog for some great tips on how to set yourself up - I borrowed shamelessly from it but did a lot of tweaking for my needs.

For example:

We do a lot of VFP->.NET conversions and we've found that as part of the conversion strategy, we frequently have to write apps that use SQL: data while using VFP data for some tables that for one reason or another have not yet been converted. To accommodate that, we modified all of the methods in the data layer to handle both backends so that the programmer's code can be relatively platform independent, facilitating a later conversion of the VFP table.

Unfortunately, sending parameters to an OLEDB VFP query or update is quite different from the SQL counterpart. Taking care of that in the data layer will keep you app clean.


Take a crack at it if you have the time.
It's a great way to become familiar with the nuances of data layers, datasets and datatables.

If you get stuck ask questions here.. I've gotten some good help here....
or email me off line and I'll send you the code and some sample calls.