I was thinking aloing those lines on the way home last night. I have a 180 mile round trip each so I get plenty
of time to think.

At any rate, my problem with this is that the user won't know that the back end changed until AFTER they hit Save.

What do you do at this point?



>Kevin,
>If you need basic locking functionality may I suggest having an UpdatedDate field in your database. Set it originally to a default value (1/1/1900 or something of that sort). The value should make a round trip from the database, through all of your data processing, and back to the database. In your Update Stored Proc, update the record if and only if the UpdatedDate on the record matches the @UpdatedDate parameter you pass in. If the update succeeds, make sure you increment the UpdateDate field back to the current date.
>
>Using this method ensures you are always overwriting the same version of the record you originally retrieved.
>
>>Excellent.
>>
>>What can I do to handle locking/user conflicts?
>>
>>
>>
>>
>>>>Now that I have recieved the data as XML in the server side class, can you recommend a technique for
>>>>getting the data back into the DB?
>>>
>>>OK, well, you've already figured out how to get the XML back into the DataSet using the StreamReader with the .ReadXml() method (we include a method that does that in all of our DataSet classes).
>>>
>>>And somewhere in this thread, someone (I think Mike), suggested a way for updating your database and it's basically the way that we do things. Here's something I have posted here many times, but it's easier to post it again rather than search for a message <g>:
>>>
>>>There are a few more options when updating the database.
>>>
>>>First, you can use the Update method of the DataAdapter. In order for this to work, your DataSet must have a PrimaryKey defined.
>>>
>>>You can do it using the CommandBuilder, which will generate update commands for you (note: if you use a Stored Proc, the CommandBuilder only generates the proper insert/update/delete commands for the first table retreived from the Stored Proc):
>>>

>>>public void UpdateMyData(DataSet ds)
>>>{
>>>	// The same applies for the Update. It's not necessary to Open/Close the connection.
>>>	SqlDataAdapter da = new SqlDataAdapter("select * from bob", this.oConnection);
>>>	SqlCommandBuilder sb = new SqlCommandBuilder(da);
>>>
>>>	da.Update(ds);
>>>}
>>>

>>>Or you can create the various update commands yourself instead of using the CommandBuilder:
>>>

>>>public void UpdateMyData(DataSet ds)
>>>{
>>>
>>>	SqlCommand sc = new SqlCommand();
>>>	sc.Connection = this.oConnection;
>>>	da = new SqlDataAdapter(sc);
>>>
>>>	da.InsertCommand = new SqlCommand("Insert into bob (xyz, abc) VALUES ( @xyz, @abc )", sc.Connection);
>>>	da.InsertCommand.Parameters.Add("@xyz", SqlDbType.Int, 8, "xyz");
>>>	da.InsertCommand.Parameters.Add("@abc", SqlDbType.VarChar, 50, "abc");
>>>
>>>	// do the same for da.DeleteCommand & da.UpdateCommand
>>>
>>>	da.Update(ds);
>>>}
>>>

>>>Or, you can take total control, not use the da.Update() and do it all yourself (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 :
>>>				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