In general I have been getting very strange behavior when using rowVersion or timestamp concurrency with stored procedures. For instance in the update stored procedure, even though I return the new version of the either the rowVersion or the timestamp column, I get a conflict message prompting me to select which changes to keep.

I have used the SFSUsers_Insert, Update, Delete stored procedures as a model.

I have also noticed using the SQL Profiler some parameters passed to the stored procedure not mentioned anywhere in the documentation. Parameters who's name is ending in _ORGK. I assume that those are the original values of the row for comparison reasons.

Are there any samples available of how to use stored procedures for the Insert, Update, Delete operation of a BO, using either RowVersion or Timestamp concurrency? I have the feeling that I'm missing something.

Thank you for your time.

George Nentidis

Hi there!

I try to modify the CRUD properties of a BO. The BO has a primary key of type Guid (uniqueidentifier in SQL Server) which I set its default value on the BO_SetDefaultValues event. I have set the PrimaryKeyIsAutoIncremented to False. I have set the InsertUsingStoredProcedure to True and also defined a stored procedure name in the InsertStoredProcedureName property. I have set the UpdateConcurrencyType to OptimisticsTimestamp and also defined a column name in the RowVersionOrTimestamp column. I have defined this column as an output parameter in the insert stored procedure.

I add a new row with the BO.Add method, edit some data in the form and then call the Save method. The row is added ok in the data base, but the IsDirty flag remains True. I can see in the CurrentDataTable that the row added with the BO.Add member has still a RowState of DataViewRowState.Added after the Save. I guess this is why IsDirty is True. Is this supposed to happen, or am I doing something wrong?

Thank you for your time.

George Nentidis