This sample (in C# for now) can be used to investigate how concurrency checking/resolution works in SF. The application has a single form that uses a splitter to show two customer forms (from the StrataFrameSample db's Customers table). Each side uses its own BO. Thus you can change one side, and while on the same record, change other side and see how concurrency works.



This also shows one of the ways you can customize concurrency by manipulating the FieldsCollisions provided to the standard SF collision form. This is used to separate "system" collisions, such as those that will occur with row version or time stamp columns from "user" collisions. With this customization, the system collisions are now shown and are handled automatically.



You can turn on/off this customization via the Auto Handle Concurrency checkbox at the bottom of the form. You can also turn on/off debugging the data source (sql debugging) on the bottom. There is a link to the debug file there also.



To summarize how concurrency works:



1. First it is determined if there is a concurrency issue. This is done via a combination of a concurrency check within the insert/update/delete statement (check if current row version/timestamp/all fields match the server values) which if it fails will result in no data being changed on the server and on a check of the record count (zero if concurrency check fails).



2. If there is a concurrency issue, a list of fields that will collide with the values on the server is built, to allow the user (or the app) to decide which of the collided values to use.



Collisions are determined at the field level and can be defined to mean that the user is updating a field without knowing the state of the value on the server and the update would change the value on the server.



What happens with a concurrency issue is controlled at the form level with the AutoHandleCollisions property and the CollisionNotificationType property of BOs. (How concurrency is checked is controlled at the BO level by the RowVersionOrTimeStampColumn, UpdateConcurrencyType and DeleteConcurrencyType properties.) When an event is raised for concurrency issues, you are provided with a collection of all fields that colliding. You can manipulate this collection as needed and/or provide your own form (not shown in demo) to show the collisions or any other information needed.



A couple forum posts on concurrency:



http://forum.strataframe.net/FindPost6191.aspx



http://forum.strataframe.net/FindPost5006.aspx

Greg,

When I try to run this sample I get an error indicating that the column named cust_InitialPurchaseDate does not belong to the table Customers in the StrataFrameSample database.  Do I need to download a new Customers table?

Sam

You likely are running an older version of SF. I built this on 1.7.0.6. The sample database has changed a while ago.



So, either install the latest version of SF (I'd do 1.7.0.7 myself, but at least 1.7.0.6) OR rebuild the partial for both of the customer BOs (CustomersBO and CustomersWithDescBO, but not CustomerBaseBO) and then fix the bindings on the fields in the form, and you might have to fix the methods in the CustomersBaseBO that determine what systems fields are too.

Hi Sam.

I guess Greg had made some change to his Customers table. If you have access to it, add the column to the table in some way. Running a new query like this on your StrataFrameSample database will work:

Oops, or what Greg has just said...

I think that the cust_InitialPurchaseDate field is one I added when doing some other test using the sample database. So most of you will need to add this field. I'd use this T-SQL to do that:





It allows nulls in my database and has set/replace rules built into the BO.