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

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"

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

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

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

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.

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

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

Thanks for that - nothings ever easy is it.....

So I take it the recommended approach is to have a row version that is only maintained by SF, i.e. no triggers. If this is so I presume then, if I have a proc that does some work that I want SF to be aware of, I change the value in the row version, e.g. decrement it?

Cheers, Peter

In this case you would probably want to increment rather than decrement it...but otherwise, yes.