Cathi,

We made that decision quite awhile ago and I don't remember all the reasons, but I think it mainly had to do with flexibility. When you "roll your own" you can make it do anything you want. I think the DataAdapter way of doing things was too limiting for us. Now, I will admit that at this point, I don't remember what all the issues were ... just that it seemed to us at the time that this way was the best way of handling updates.

If I think of any specific things, I'll get back to you.

~~Bonnie



>Just for my curiousity, what was the reason for not using a DataAdapter to perform the updates for you, calling the different stored procedures?
>
>>Nope. We're getting the changed data, spinning thru each row, setting the necessary parameters for the SP and updating one row at a time.
>>
>>
>>>Are you sending the data as Diffgrams to your stored procedure for batch updates?
>>>
>>>>No, we're not using the DataAdapter for updates, only for filling DataSets. For updates, we just use SqlCommand.ExecuteNonQuery().
>>>>
>>>>~~Bonnie
>>>>
>>>>
>>>>>Are you even using the DataAdapter? This approach was the different ways to use the Update method of a DataAdapter. There are many different ways to perform updates in general.
>>>>>
>>>>>>Hmmmm .... interesting. Thanks Cathi ... it's not the way we're doing it, but no one says we're doing it the right way. <g> I guess there's more than one way to skin a cat ... it's nice to have several options.
>>>>>>
>>>>>>~~Bonnie