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

Hi Guys,

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

I understand....just so you know, there is less that can go wrong using a row version versus a time stamp column.

Peter,



You have a good point about the user of sprocs and maintaining the row version column. Another issue to consider is the user of triggers. If you use triggers, it is actually better to use the row version (from what I've read) because with concurrency checking using either all rows or a timestamp, you end up having problems because SF can't keep up. I.e. if you have trigger that is fired and does an update of some table, the BO that is hitting the updated table will become out of date (as the timestamp will have changed or some data in the table will have changed) and will through a concurrency error. The forum posts all suggested using row version concurrency because the trigger typically wouldn't update the row version, and in many cases the trigger is maintaining some system controlled data anyway. There are posts about it in this forum and probably the issues forum. Try searching for concurrency or row version.



Hope this helps!



Greg

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

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. 

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

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.

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

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."