I first summarize my question then follow it with more detail.

When SF is saving an updated record, does it write back every column of the record or only those columns that were affected.



User1 opens customers 1020 to update the email address of the customer. While she is on the phone with the customer [and has not pressed the save button yet], another process in the system [say invoicing] updates the customer balance. (Optimistic Concurrency).



User finishes with the customer and presses the save button:

a) Does SF write back ONLY Email column back without affecting the new balance?

b) Does SF write back the WHOLE record back and putting the old Balance to the database?

c) Or does SF raise an error that the record has been changed since it was originally read?



if C, then what action is left for the end user to take to make sure the balance is not affected and still the email is updated too?

Is it something that the SF has a built-in in the data access layer or do we (as the developer) have to take action for every update situation?



Thanks!


..ßen

Bradley,

The zip file didn't get attached, would you mind posting it again? 

The reason that SET NOCOUNT ON causes the business object to think that there is a concurrency exception is that the DAL tests the ExecuteNonQuery() return value to determine how many records were affected by the query.  If SET NOCOUNT ON is used, then an UPDATE returns 0 records modified, so the business object thinks that no records were updated... meaning there was a concurrency excepton. 

SET NOCOUNT ON is fine for sprocs that return result sets or single values, but CRUD sprocs require the rowcount to determine whether or not they went through.