Row added with Insert stored procedure does not update IsDirty


Author
Message
George Nentidis
George Nentidis
StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)
Group: Forum Members
Posts: 72, Visits: 251
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

Replies
StrataFrame Team
S
StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
1) I'm glad you got that working Wink

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.

StrataFrame Team
S
StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
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.
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search