Hi,

I want to use a timestamp for concurrency control and I can't figure out how I should configure the timestamp field in the BO Mapper. Whatever I try causes either compile or runtime errors. What is the recommended way of configuring a timestamp in the BO Mapper and is there anything I should be doing in _SetDefaultValues to set an initial value for a new record?

Cheers, Peter

All you need to do is create the time stamp column, edit the BO through the component designer (double-click the BO) and set the ConcurrencyMode to OptimisticTimeStamp and then set the RowVersionOrTimeStamp column with the name of your field.

Note: This is outlined step-by-step in the help documentation and goes into much more detail than I have here.  I recommend looking at the documentation for a more replete answer.

Help Documentation
Application Framework -> Business Layer -> Common Business Object Tasks -> Implementing Concurency

There is a link at the top that says "Optimistic Using a Timestamp Field"

Hi,

Yes, I've done all that - my question was: "I can't figure out how I should configure the timestamp field in the BO Mapper."

For instance, if I use "nullable generic" I get :Error 1 Type argument '1-dimensional array of Byte' does not satisfy the 'Structure' constraint for type parameter 'T'

If use Return Alternate on Nulls/Set Alternate on null (value type) and set the alternate to Nothing I get Error 1 Operator '<>' is not defined for types '1-dimensional array of Byte' and '1-dimensional array of Byte'. Use 'Is' operator to compare two reference types.

I was hoping you could have just save me from just trying things until I stumbled across the right combination.

Cheers, Peter

 

Hi,

For anyone interested setting the timestamp column in the BO Mapper to "Return Alternate on Null" with a return value of "Nothing" seems to work ok.

Cheers, Peter

I just saw your two posts and you are correct.  You have to use Return Alternate on NULL rather than a Nullable Generic.  You can return nothing, or return a "default" date such as "1/1/1800."

Hi Trent,

Thanks for the extra comments however I don't think a date value would work (although I haven't tried it). A SQL Server timestamp column is (to the best of my knowledge) not a date but simply a guaranteed unique incrementing number allocated by SQL Server to show the order in which database updates are commited. I think this is database wide value rather than a table specific value. Thus, if my timestamp on read was 345763459234 and the current timestamp value is different, then the row has been updated since my read.

Cheers, Peter

Hi Peter.

Isn't it a row version you are trying to implement?

Instead of setting the BO's ConcurrencyMode to OptimisticTimeStamp, you could choose OptimisticRowVersion. Have an integer field in the table to handle it, and then set the RowVersionOrTimeStamp column with this field name, as Trent mentioned.

Hope it helps.

Hello Ivan,

StrataFrame supports both ways of handling concurrency, either row version or timestamp. The advantage with timestamp is that the value is automatically maintained by SQL Server, i.e. no need to maintain a row version number in your code or fire a trigger when a table is updated. All you need to do is a add a field with a data type of Timestamp into each of your tables and that's it - nothing more to do. The name "Timestamp" is misleading in that it is only a relative time stamp, e.g. you know that update 1234 happened before 1235 but the actual updates may have milliseconds or days apart, there is no way of knowing.

Cheers, Peter

True...but this also complicates things.  StrataFrame automatically manages the Row Version for you, which actually requires slightly less overhead than using a time stamp column.  So really if you are looking for a field versioning concurrency model, row version will actually be the best since it is literally a matter of creating the integer field and assigning it to the BO as you would a time stamp column. 

Hi Trent,

Thanks for that - I didn't realise that SF actually handles the updating of the row version column. I will have to have a think about what's best to do. My initial thoughts are to stay with the TimeStamp column as it doesn't rely on the use of SF to keep track of things, for instance if we fire a stored proc to do some work then concurrency control is maintained without having to make sure the proc updates the row version as well as doing whatever other updating is needed.

Cheers, Peter