CSLA 3.8 Templates - Insert Stored Procedure for GUID Primary keys generating NewID

[GoogleCodeExporter]

When you have a GUID as a primary key the CSLA 3.8 Templates are correctly 
generating a Guid.NewGuid within the editable object's DataAccess 
DataPortal_Create() code. However, the generated stored procedure's Insert 
statment is also generating the following:

SET @p_ID = NEWID()

This results in the stored procedure creating the ID and then this ID replaces 
the ID created in the business object.  If you have any UI code that stored the 
object's ID before the save was executed then the IDs will nolonger match.

The SET @p_ID = NEWID() statement in the stored procedure should be removed for 
GUIDs, and the ID field should not be defined as Output for GUID datatypes.

Original issue reported on code.google.com by jodyches...@comcast.net on 20 Sep 2010 at 5:04

[GoogleCodeExporter]

Hello,

This makes sense, I think this was set initially for the rules so the 
RuleManager doesn't error out. Do you know what others are doing for this? Is 
your column a nullable guid?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 21 Sep 2010 at 8:56

• Changed state: Investigating
• Added labels: Type-Defect, Priority-High, Framework-CSLA

[GoogleCodeExporter]

In our shop we like the business object to set this value in the 
DataPortal_Create() method so that our UI can use this if needed (prior to 
saving the object).  For us the database still has this field marked as not 
nullable and business object is changed to make this property readonly.

Original comment by jodyches...@comcast.net on 22 Sep 2010 at 4:15

[GoogleCodeExporter]

Hello,

That makes sense. I think that this was set to get the value back from SQL 
Server because SQL Server uses NewID which is always unique. Have you ever run 
into a SQL constraint error by setting this from your business object?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 27 Sep 2010 at 12:12

[GoogleCodeExporter]

I am not aware of any SQL constraint errors.  Generally, the database is always 
updated via the business objects so this field is always populated.  However, 
on some of our database projects we have also defined a default value of 
(NewID()) on the GUID primary key column, in the event the database is manually 
updated.  Therefore, we don't need to have the NewID() defined in the insert sp.

Assuming you update the templates with this change, do you know when they will 
be updated?  Thanks again for your help.  The templates are a wonderful time 
saver! 

Original comment by jodyches...@comcast.net on 27 Sep 2010 at 4:06

[GoogleCodeExporter]

Hello,

I'm not sure on how long it would take to get implemented. If you would like to 
take a stab at this, it would be a greatly appreciated. I like to get community 
involvement so others can contribute as well :). This increases the value of 
the templates (I think) and opens up the generated output to improvement and 
places where we could improve.

If your up to it, please let us know. I'll be here to help with any questions 
or issues. I believe one would just need to update the templates in the common 
folder. Also there should be one spot in the source code (located in the 
\source folder, it would be an extension methods for the update/insert logic).

Please let us know if you have any questions.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 30 Sep 2010 at 2:35

• Changed state: Accepted

[GoogleCodeExporter]

Hello,

This guid identity key will be updated after the inital inset with the value 
from the database. SETID ensures that the value is unique in SQL Server where 
Guid.NewGuid() ensures that it may be unique on the client. If your UI is 
databound then this should automatically be updated. I'm trying to think of a 
way to ease this issue. If you have any thoughts or ideas it would be greatly 
appreciated.

Original comment by bniemyjski on 13 Mar 2012 at 4:29

• Changed state: UnderConsideration
• Removed labels: Priority-High