>I guess I don't understand the need for the parameters. You're building an insert statement for each new row, and the row values
>are part of the insert statement, so what do the params do?

Well, as I said, I actually prefer to use Stored Procs, but even setting parameters like this, it's usefulness is that it keeps your data types correct. Look at it this way, how would you do an INSERT with a DateTime column? You wouldn't want to plug in the DateTime.ToString() (which you would have to do if you simply put it all in the CommandText string.

~~Bonnie



>
>
>
>>>I get it in theory, but I'm not all there syntactially. I'd like to see the code, if it's not too much trbl.
>>
>>Quickie: this is basically the same code that gets done behind the scenes by the da.Update() method:
>>
>>

>>public void UpdateMyData(DataSet ds)
>>{
>>	SqlCommand sc = new SqlCommand();
>>	sc.Connection = this.oConnection;
>>	sc.Connection.Open();
>>	foreach (DataRow Row in ds.Tables[0].Rows)
>>	{
>>		switch (Row.RowState)
>>		{
>>			case DataRowState.Added :
>>				// or use a StoredProc, which I prefer
>>				sc.CommandText = "Insert into bob (xyz, abc) VALUES ( @xyz, @abc )";
>>				sc.Parameters.Clear();
>>				sc.Parameters.Add("@xyz", Row["xyz"]);
>>				sc.Parameters.Add("@abc", Row["abc"]);
>>				sc.ExecuteNonQuery();
>>				break;
>>				
>>			// Do the same for DataRowState Deleted and Modified
>>			case DataRowState.Deleted :
>>				break;
>>			case DataRowState.Modified :
>>				break;
>>		}
>>	}
>>	sc.Connection.Close();
>>}
>>

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