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

Reply
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
Ok, panic!!!

I have spend the whole day and didn't manage to save a single object correctly, have seen lots of exceptions, and still don't know what to do. Things should really not be that difficult, and there are some things that don't seem to work correctly. I could really use some help.

I have attached a RAR file with the stored procedured I have created, the screen shot of the conflict window, and a text file which contains a portion of the trace file from SQL Server Profiler.

Here are the issues I have gathered.

1. The DDT generates stored procedures that are just like those I have created with one exception: The update auto-generated procedure from the DDT, does not contain the @contactID_ORGPK parameter that the framework adds to the call. I found about this parameter by using SQL Server Profiler. There is no such column in my BO, and my guess is that this parameter contains the original value of the primary key for comparisson. Still it is not generated by the DDT nor is mentioned in the documentation. I have also compared my stored procedures with the ones described in the documentation you mentioned in your previous post.

2. After inserting a new row by a) calling the BO.Add b) modify the values c) BO.Save, my insert stored procedure is called correctly, the row is saved on the database, but the IsDirty flag of the BO is still true because the CurrentDataTable still has the new row in the DataViewRowState.Added state. Of course this has as a result, when trying to close the form for the "Save Changes dialog" to show.

3.1 After editing a row and calling BO.Save, my update stored procedure is called, but a conflict window is displayed, even though there is no conflict. You can see a screen-shot of the window in the attached RAR file. If I click the Save button on the window, again the same window is displayed with the values of the Version column increased by one. The same thing goes on and on. The same happens for both the RowVersion and Timestamp cases.

3.2 Each time my update stored procedure is called, the framework makes another SELECT statement immediatelly after the call to my stored procedure. You can see the SELECT statement in the "SQL Profiler Trace.txt" file in the attached RAR file. Is this correct? What's the point of specifying a stored procedure if another SELECT statement will follow?

4. This is not very important for me right now, but when importing in the DDT my table which contains a primary key of type UniqueIdentifier, it is imported actually as a type of Int.

I really hope I'm doing something wrong. I am about to give up the whole stored procedures idea, but still...

Thank you for your time,

George Nentidis

Attachments
Files.rar (116 views, 44.00 KB)
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