>So you form a client-side Update command and send it for each row that has changed?

Not exactly. None of my DataAccess is client-side (I only access the back-end through Web Service methods, sending only the changed rows in my DataSets), so this is server-side stuff and it resides in my DataAccess classes. I don't set up an Update command per se ... as I said, I spin through every changed row in each table I want to update, and for each of those rows set parameters and ExecuteNonQuery.And, as Kevin G suggested, I only use Stored Procs. So, I'm not calling any Update method at all.

~~Bonnie



>>>I don't understand how ADO can make changes to the underlying table. I mean, in the resulting DS, assume I change the value of
>>>ModuleTypeKey, which is in a JOINed table. If I then call Update, how does ADO know which table to put the changes in?
>>
>>>It's amazing how well my code works when I code it right! Thanks.
>>
>>You're welcome! =0)
>>
>>>A related question.
>>
>>>I don't understand how ADO can make changes to the underlying table. I mean, in the resulting DS, assume I change the value of
>>>ModuleTypeKey, which is in a JOINed table. If I then call Update, how does ADO know which table to put the changes in?
>>
>>I don't think it *can* know it. Which is why I don't use the Update ... I roll my own (basically, spin through every changed row in the table you want to update, and for each of those rows set parameters and ExecuteNonQuery. It's basically what the Update does behind the scenes, but you obviously have more control over it). We've have a set of "parameter" methods that do things like automatically set parameters.
>
>So you form a client-side Update command and send it for each row that has changed?