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

End of panic... It's a nice thing to provide the source code of the framework. Not the easiest way to find a solution but better than nothing.

1. The _ORGPK parameters are added if the PrimaryKeyIsAutoIncrement is False. It is used only in the update stored procedure. More such parameters are added if the concurrecy is set to OptimisticAllFields.

2, 3. The whole problem was caused because of the SET NOCOUNT ON statement existed in my stored procedures. Unfortunatelly if you create a stored procedure using the SQL 2005 Server Management Studio, this line is automatically added. The framework could not get the number of rows affected and all those bad things happened.

4. Is still true.

Perhaps you should add something about all these in the documentation or even better to provider a sample of using the BOs with stored procedures.

Thanks once again,

George Nentidis

1) I'm glad you got that working

2, 3) Yep, when you use the SQL Server Management Studio 2005 template to create a new sproc, it does add that SET NOCOUNT ON.  Supposedly, it's to help you improve performance because it tells SQL Server that it doesn't have to keep track of the number of records that are modified.  If you're not creating a CRUD stored procedure, then this is great... there's no need to keep track of modified records, but if you're modifying records, then yes, you will need to remove that call from the sproc template before saving your sproc.

4) I will add a bug for that.  Thanks.

4) In the meantime, the workaround would be to import your database and change the primary keys back to UniqueIdentifier BEFORE you deploy the database through the DDT.  Once a PK column is created, it must be dropped and recreated to change it.