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

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

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

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