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

a)  Yes, every column is updated.
b/c)  You have several options... the CollisionNotificationType property tells the business object how to handle it.  If the property is set to RaiseEvent (default), then the concurrency exception will be found, the save process paused, a list of field collisions generated, the event is raised, the event args are set to tell the DAL which field value to save or overwrite (on a per-field basis), and the record is optionally resaved.  This option is the default because the form automatically handles the event (set by the AutoHandleCollisions property on BaseForm).  A pretty form is shown, informing the user that a data collision has occurred and asking them to choose the value.  If the event is not handled, the default values of the event args allow the record to re-save and take the server values for each field that was conficting.  You can also set the CollisionNotificationType property to ThrowException.  This causes an exception to be thrown during the save process.  You would then have to manually choose the values and resave the record(s).

Hi Ben; Thanks for the reply!







So in this case the user can tell SF to only save email field (that she has changed) and not touch the balance field?

..ßen

Correct, it will show them that the ballance field is different, but they can choose to take either the server's value or their value and then resave the record.

Excellent! Man I think I'm getting to like this product

..ßen

Ben (Strata), take a look at this post. It describes how to control the field names shown to the user. I.e. if your field is named user_email in the db, then it will also be named that in the BO and that is the name that will be shown on the concurrency form. This post describes how to change what the concurrency form shows.

Of course it would help if I actually posted the link!



http://forum.strataframe.net/Topic5006-6-1.aspx#bm5040

Greg, your input is much appreciated. I think the time is coming where MicrFour needs to build a Knowledgebase system with all the questions and answers in a hierarchical format. I think the team is answering the same questions more than once. And to preserve the support resources, a knowledgebase would save time on each side?



Or should I put this proposal in the enhancement section?


..ßen

A great idea. I was just thinking something like this earlier today, as I tried to find a post I'd read a while ago. I'd suggest posting in the enhancement area. This would let other uses (who may be ignoring this post) chime in with their $.02.

Done!

..ßen