<<
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???



>One of the "gotchas" with bringing down multiple tables with one SP, is that the table names are *always* table, Table1, Table2, etc. and I haven't found any way around that. So, you have to have your DataSet tables named appropriately. But, since we use typed DataSets, it's no big deal ... we can name our tables however we want to in the typed DataSet and thus have meaningful names to access our tables with.
>
>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.
>
>~~Bonnie
>
>
>>Yep, it works for me. I kept running into problems before. IAC, what if you have multiple tables in the dataset? How do you handle that as well as updates right now???
>>