Yep, you got it ... the DataAdapter is *only* used to Fill.

And yes, I agree that it's not always a good idea to let VS handle this stuff for you! <g> I don't remember all of the garbage that VS creates for you when you you do this visually ... it's been awhile since I've done it that way.

It's quite easy enough to programmatically loop through your tables and columns to generically add the Parameters for your SP's if you follow a few conventions all the time for your SP's ... if you use auto-generating tools that will generate SQL script for you to create your SP's and to create your DataSets, then all is done easily enough. We've written a few tools (mostly in VFP ... one in .NET for creating a DataSet's .xsd) to plop stuff on the Clipboard that we can paste anywhere, so it's really easy to do some of this stuff.

~~Bonnie

><<
>As I said previously with the updates, we have the "roll-your-own" approach ... setting the SqlCommand to the SP, adding the Parameters (PK's usually) and doing a ExecuteNonQuery() seems to cover all the bases.
><<
>
>Okay... this is starting to make sense... I can see how filling a dataset could be done without mappings. The update process however, requires that the data adapter to have mappings that brokers data from the dataset to the parameters of the update command.
>
>In this case, it looks like you are using the data adapter to fill only. You are rolling your own approach for inserts, updates, and deletes, yes????
>
>Going over again the stuff I was working on, the update method was crapping out due to a lack of mapping info. If you look at what you get when you let VS generate this stuff for you, there is a ton of setup code that IMO, is a lot of extra bagage to carry around.
>
>Your thoughts???