I tried to use the Row date time stamp column on a bo but it did not update the column after a save. I ended up implementing my own because I wanted some additional auditing functionality so I did not spend much time looking at it so it is possible it is just me not SF.

Paul

UpdateConcurrencyType = OptimisticTimeStamp
RowVersionOrTimestampColumn = "YourDateTimeField"

That's all you have to do.  The same is true for the row versioning, which is more commonly used:

UpdateConcurrencyType = OptimisticRowVersion
RowVersionOrTimestampColumn = "YourIntegerField"

I must not have set UpdateConcurrencyType = OptimisticTimeStamp. I know that the field name was set correctly because I did double check that. Like I said I thought it might have been me.   

This is done if I don't set them to be created as Stored Procedures in the DDT Table Properties, right? Then I should set the properties of the BOs created in my BO Library. Sorry for the basic question, but what would be the advantage of both approaches ? That is, if I haven't got them all wrong.

Thanks.

Even if you are using the DDT to create your stored procedures, and you want to use RowVersioning, you still have to set the RowVersionOrTimeStampColumn and the UpdateConcurrencyType properties on the BO for this to take effect.  If you are letting the DDT create the stored procedures for you, you still have to set the InsertUsingStoredProcedure, Update..., etc. to True...but you do not have to provide the InsertStoredProcedureName, etc.

Well, allowing the framework to manage your row versioning is going to be faster simply due to the fact that all of this is inline to the data saving within the framework...thus you pick up speed.  Additionally, if you use the stored procedures that support the Row Versioning as well, then you gain even more speed...using the DDT created stored procedures with the BOs and the concurrecy is going to give you the optimum performance.

Right, I will take the optimum performance then.

Thanks Trent.