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

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

George,

I would try a couple of things.  First, there is some documentation that explains the CRUD Stored Procs that are expected by the BOs.  If you use the Database Deployment Toolkit (DDT) you can have it produce these procs for you.  Look at the help topic in the DDT titled "Table CRUD Stored Procedures."

Next, create a profile and a database through the DDT and allow it to create some procs for you.  You can then look at these procs once they are deployed to a server and compare them to what you are producing.  This may give you a clue pretty quick once you see what we produce and use.