StoreGeneratedPattern Property in ADO.NET Entity Model Designer sets CDSL annotation but not SSDL attribute. - by Joel-MMCC

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 505178 Comments
Status Closed Workarounds
Type Bug Repros 59
Opened 10/28/2009 11:28:09 AM
Access Restriction Public


Using the VS2010 ADO.NET Entity Model Designer for an .EDMX file to set the “StoreGeneratedPattern” Property of a database column (a feature not available at all in the ADO.NET Entity Model Designer of VS2008 SP1 — thanks for exposing that Property in the Designer, but right now it’s dangerous!) and associated Entity Property to “Identity” or “Computed” only sets the “a:StoredGeneratedPattern” Attribute in the Entity Property entry in the CDSL section of the file. It really should also set the “StoredGeneratedPattern” Property on the corresponding database column entry in the SSDL, or the expected behavior will not occur in LINQ-to-Entities code (Properties connected to such columns will not auto-populate after a SaveChanges is performed on the Entity Context, and worse, invalid null or default values will be written to those database fields, OVERWRITING what the database generated!).
Sign in to post a comment.
Posted by nZeus on 4/25/2012 at 2:59 AM

VS 2010 SP1, EF 4

Hotfix installed successfully, computer was restarted.
Still have ths same issue - there are no StoreGeneratedPattern property for the GUID columns in the SSDL annotation :(

Database: MSSQL 2008 R2.

Unfortunately, bug is not fixed.

Best regards,
Posted by Linard Moll [MIT-GROUP] on 4/20/2012 at 9:57 AM
Working for VS2010 SP1 + EF 4.3.1

.... Finally !!!
Posted by sarahmcd on 2/27/2012 at 2:41 PM
and you have SP1 installed for Visual Studio 2010?
Posted by Prethen on 2/27/2012 at 2:00 PM
I'm using VS 2010 on Win7-64-bit and we definitely have this same issue today. When will this bug be fixed?
Posted by Microsoft on 12/9/2011 at 4:19 PM
Hi Cedric,
It should work on a Windows 7 64 bit machine -- what is your version of Visual Studio?

Sarah McDevitt
Posted by Cédric Lévêque on 9/23/2011 at 7:17 AM
Hi all,

I have the same bug and I have tried to apply the fix but it doesn't work.
When I run the fix, I have a warning that says the fix can't be apply on my computer, may be because I'm on Windows 7 64 bit.

Someone can do something for me ? Or should I wait for a SP2 ?

Posted by bannister.nick on 8/19/2011 at 7:55 AM
Hi all,

I actually think I need to retract my previous comment. It appears not to work but it does. The fix doesn't make the CSDL and SSDL match it just 'knows' from the setting in the edmx that you are specifying it as an intetity field and simply works.
I presume others may have made the same mistake as me thinking the fix was going to do the workaround around we have all being doing but it doesn't do that. It just works ... :)

FYI: I tried the latest hotfix released 3 days ago too!

Posted by bannister.nick on 8/19/2011 at 3:38 AM
Hi all,

I have tested this latest hotfix for KB2561001 added 3 days ago and can report the issue is still not resolved!!
I have updated my machine with every single windows update possible and any for VS 2010 and the property still gets removed after I have added it in.

I do not mind testing the hotfix but it seems two attempts have been made to fix this and neither have worked.

@Sarah, I have emailed you about this.

I really could do with this being fixed I sympathise for those who have to keep re-editing the same thing over and over and for a new development this is so SO painful!

Posted by sarahmcd on 8/16/2011 at 2:05 PM
Hi all,
Thanks to everyone who helped test the fix. The released hotfix is now available for you to download!

Code Gallery:

Thank you,
Sarah McDevitt
Program Manager
SQL Server Data Tools
Posted by HiredMind on 8/12/2011 at 8:44 AM
Just so everyone knows, the hotfix seems to work, at least for me. So there is light at the end of the tunnel :)

You should contact Sarah and help test it, to get it into the update stream as soon as possible...

Posted by HiredMind on 6/16/2011 at 10:26 AM
Hi Sarah,

It appears that the watchlist for this bug is not notifying people when comments are added (Possibly because it is "Closed" - Ahem...). This is probably why you have received very few volunteers. If you see this before they do, can you poke the Connect website people about it?

Posted by sarahmcd on 6/9/2011 at 10:45 AM
Hi all,
I've received very few volunteers to test the patch, please let me know as soon as possible if you would be willing to validate the Hotfix with us so that we can get the fix in customers' hands.

See the post below for additional details, and please let me know at

Thank you!
Sarah McDevitt
Program Manager
Posted by sarahmcd on 6/6/2011 at 11:32 PM
To all customers hitting this issue:

Thank you all for providing your feedback and specific issues around this Connect bug. We have developed a fix that we are actively testing right now and are at the point where we need a few customers to validate the fix. Assuming the fix is verified, we will release this as a Hotfix to you as soon as possible.

The validation will involve installing a pre-release Hotfix for the Entity Designer in Visual Studio 2010 on a machine with Visual Studio 2010 SP1, then using the same constructs and repros that you have been using that bring about the problem. The Test Hotfix will be in the form of a full install/uninstall package, which should enable you to roll back to your previous state of Visual Studio 2010 SP1 as needed. However, as with all pre-release software, unexpected behavior can occur that we may not be able to directly support, and if you are not comfortable with this you should not sign up to help verify the Test Hotfix.

Qualifications to participate in the Hotfix validation:
-    You regularly experience the StoreGeneratedPattern property issue described in this Connect bug
-    You have .edmx artifacts you can use or can reproduce those artifacts that have caused this issue
-    You are willing to take on the risk of unexpected behavior due to installing pre-release software

If you meet these qualifications and would like to participate, please let me know at sarahmcd at microsoft dot com with the email subject line “Volunteering for SGP Hotfix.” If you can note briefly (can be 1-2 sentences) your scenario in which you have dealt with this bug, that’d be great. I will select a set of participants and then post back here to close the invite, and will post again of course after the validation phase to update you on the status of the fix.

Thank you once again for your feedback and for your patience with this issue.

Sarah McDevitt
Program Manager
SQL Server Data Tools
Posted by Batuhan Akçay on 5/26/2011 at 5:38 AM
This has to be a damn joke, how come this cannot be fixed since 2009 ? this bug is really REALLY annoying.
i like ef, but this is killing me.
Posted by ownmaster on 5/18/2011 at 8:31 AM
So, this bug is not fixed yet. Maybe you can release small patch before SP2 (if there will be SP2)?
Posted by Bill__Bates on 5/9/2011 at 1:11 PM
This is a joke. All of a sudden, because a few default values were added to the schema, my ERF based system broke. I am SO disapointed at Microsoft. Usually I wait so that these things are fixed. Sync model to database should mean just that! changes in names, types, nullable or not, EVERYTHING
Posted by Bill__Bates on 5/9/2011 at 1:11 PM
This is a joke. All of a sudden, because a few default values were added to the schema, my ERF based system broke. I am SO disapointed at Microsoft. Usually I wait so that these things are fixed. Sync model to database should mean just that! changes in names, types, nullable or not, EVERYTHING
Posted by Hoetz on 5/9/2011 at 2:36 AM
This issue is still causing real pain. Please advise!
Posted by Brian Lagunas on 4/19/2011 at 1:28 PM
Can you provide any feedback on the status of the fix for this issue?
Posted by bigyes on 3/17/2011 at 6:24 AM
One more vote for this very frustrating issue ! I just can't believe this is not fixed in SP1 !!!!!!
Posted by Terry Stanfield on 3/11/2011 at 12:27 PM
This issue is not fixed with SP1 and the issue should be reopened. I share the frustration previous posters have expressed.
Posted by AdamBCollins on 3/11/2011 at 11:39 AM
I've just installed VS2010 SP1 as well, and this issue doesn't yet appear to be fixed. Am I missing something, or should it just work after SP1? I'm getting really tired of having to edit the .edmx file by hand every time I update my model.
Posted by Shane Gilbert on 3/11/2011 at 9:59 AM
I just installed VS2010 SP1 and this is STILL BROKEN! If it is fixed where is the fix?
Posted by BennyJ on 3/8/2011 at 2:32 AM
So will this fix be included in the upcoming Visual Studio SP1 or not? Will it be included in the upcoming EF 4.1 RC?

It's unbelievable you haven't been able to provide a fix since this bug has been opened in 2009!!! This is a serious issue, don't you understand that?


All your further work on EF is useless if you can't manage to fix bugs as stupid and annoying as this one!!!!!!!!!
Posted by Santiago Perez on 2/23/2011 at 1:28 PM
We are in a serious crisis! We are about one third into a very large project requiring this feature and is totally unacceptable that we are incurring additional cost on a daily basis because of this. THe DB is contantly being changed as we are in a scrum pattern and everytime we do an update from database > Boom! THis should have been disclosed from the onset and we would have gone with a more robust technology and not to mention less expensive like Java with Eclipse!

Get your act together MS or the enterprise will be taken over by the dark side and ANDROID!
Posted by Mark on 2/14/2011 at 3:02 PM
Hello Microsoft? When will a fix be available? This is a pretty damn painful bug people.
Posted by RandyGH on 1/28/2011 at 4:43 PM
Agreed. This bug is pretty bad.
Posted by Guy Grasso on 1/18/2011 at 1:30 AM
No fix in VS2010sp1 beta... This is really disappointing..
Do we need to wait until VS2012?
Come on Microsoft this bug is a real pain and its been over a year.
Please reopen this issue and do some work.
Posted by Paul Patterson on 1/7/2011 at 2:07 PM
My vote too!! The manual and workaround solutions is expensive for us to maintain.
Posted by PaulAS on 12/17/2010 at 9:18 PM
The problem remains in the VS2010sp1 beta.
Posted by Murray Bryant on 12/16/2010 at 5:49 PM
Another vote for a hotfix.

Its not fixed until it is released
Posted by Viktor T on 11/18/2010 at 4:40 AM
As there is no hotfix available right now, could someone from Microsoft please comment on this so that all of us can get some idea about when we can get it?
Posted by Richard_McIntyre on 11/18/2010 at 12:15 AM
Why is this ticket closed as fixed , where is the hotfix ?
Posted by David Brenchley on 11/16/2010 at 10:40 AM
This is killing us. I've lost days and days of work because of this.
Posted by bap3 on 10/15/2010 at 2:59 PM
I just saw where Microsoft shipped a hotfix for the VS 2010 context menu / scroll bar issue. Really? You ship a fix for a menu but not something as serious as this issue? Unbelievable! PLEASE RELEASE A HOTFIX MICROSOFT!
Posted by ElPluto on 10/13/2010 at 10:37 AM
we need a Hotfix!

Workarounds are not a valid solution because when set the storegeneratedpattern manually to computed, cannot set initial values never more. Simply are ignored.


Bad job.
Posted by Tim Laverty- MSFT on 10/11/2010 at 10:01 AM

I apologize for any confusion on the status of this bug. We've made the fix for this bug in the codebase and hence have marked it as 'fixed' but have not yet been able to ship it. It will ship in the next available vehicle for patching Visual Studio.

Thanks, Tim Laverty
Posted by JackBl1 on 10/8/2010 at 1:33 PM
Where is the fix !?!?!?!?!?!?!?!?!?!

I'm currently making a backlog of "database changes that need to be done" and only making the changes as a group when I can't wait any longer just to avoid this bug.

How is this a closed issue?

This may be closed for you, but it certainly isn't closed for those of us that have to deal with it on a daily basis.




I'm sure everyone on this thread would be more then happy to do some beta testing for you.
Posted by Piotr Kowalski1 on 10/5/2010 at 5:01 AM
It's nearly a year since bug that makes EF useless for real-world IT projects was descibed.
Am I right to assume that Microsoft has abandoned Entity Framework?
Posted by J Arnott on 9/29/2010 at 12:55 PM
How can this item be marked as fixed when no fix has been released. A comment that there will be a fix does not count as a fix for me. When will this be actually resolved??
Posted by Brian Lagunas on 9/29/2010 at 7:27 AM
Any news on when a fix will be released? Thanks.
Posted by cabichandani on 9/24/2010 at 6:41 PM
This has been killing me. Could you please release a hotfix for this?
Posted by pye on 9/24/2010 at 5:15 PM
Please release a hotfix for this. I understand there is a lot of work in testing these fixes, but seriously, why should I use this product and try to sell my clients on it when things like this add to development time?
Posted by Ken P.1 on 9/3/2010 at 11:04 AM
We ran into this problem implementing some audit and were able to use a complex data type that wired up the StorageModels so the SQL “constraint” would work. Here is our situation and fix:

Create Table thingy(
                [CreateDt]            DATETIME    NOT NULL,
        [CreateUsr]        VARCHAR (80) NOT NULL,
        [ModifyDt]            DATETIME    NOT NULL,
        [ModifyUsr]        VARCHAR (80) NOT NULL

When we pointed EF and tried all fixes mentioned, we were able to make it work but did not want to edit the xml model.

However when we completed our conceptual model something really surprising happened:

New table Def:
Create Table thingy(
                [CreateDt]            DATETIME2    NOT NULL, -- Note datetime2
        [CreateUsr]        VARCHAR (80) NOT NULL,
        [ModifyDt]            DATETIME2    NOT NULL,
        [ModifyUsr]        VARCHAR (80) NOT NULL
ALTER TABLE [thingy] ADD CONSTRAINT [DF_Job_CreateDt] DEFAULT (getdate()) FOR [CreateDt]
ALTER TABLE [thingy] ADD CONSTRAINT [DF_Job_ ModifyDt] DEFAULT (getdate()) FOR [ModifyDt]

In the EF designer we created a Complex Types “Audit” with the same four fields and set the StoreGeneratedPattern = Computed. This is a xml frag from the ConceptualModels:

<ComplexType Name="Audit">
         <Property Type="DateTime" Name="CreateDt" Nullable="false" a:SetterAccess="Private"
annotation:StoreGeneratedPattern="Computed" />
         <Property Type="String" Name="CreateUsr" Nullable="false" a:SetterAccess="Public" MaxLength="80"
FixedLength="false" Unicode="false" xmlns:a="" />
         <Property Type="DateTime" Name="ModifyDt" Nullable="false" a:SetterAccess="Private" ConcurrencyMode="None"
annotation:StoreGeneratedPattern="Computed" />
         <Property Type="String" Name="ModifyUsr" Nullable="false" a:SetterAccess="Public" MaxLength="80"
        FixedLength="false" Unicode="false" xmlns:a="" />

We then looked at the StorageModels description for DB “Thingy” the StoreGeneratedPattern was set correctly.

So by adding a Complex Type and replacing the model properties with a Complex Type, we are able to move forward with our auto generation of data using the sql constraint. The Complex Type wired up the Model and the storage correctly.

Posted by bap3 on 9/2/2010 at 7:32 PM
Would someone from Microsoft please respond? Thanks in advance.
Posted by KristoferA - Huagati Systems on 8/26/2010 at 4:05 AM
@bpaul - sorry if I upset you. :)

Just to clarify: I don't work for Microsoft. I'm the guy behind workaround #2.
Posted by bap3 on 8/24/2010 at 8:18 AM
@anderssonk - really? You really consider those valid workarounds?

- Option #1 isn't an option when "update model from database" overwrites manual fixes.
- In regards to Option #2, is Microsoft going to pay for the $15/month/user license for this tool? If so, this might be an option.

Please treat this like the CRITICAL bug that it is (since data loss is possible) and do the right thing and relase a hotfix. Thank you!
Posted by KristoferA - Huagati Systems on 8/22/2010 at 8:19 PM
@bpaul and @mh8759 - there are 3rd party workarounds that address this and other issues that can cause SSDL and CSDL to get out-of-sync. See the 'workarounds' tab on this connect item.
Posted by bap3 on 8/22/2010 at 8:12 PM
Any chance of releasing the fix as an out of band hotfix? Please? We (my company) is in the process of moving a large web application with 80+ tables to ef4. Many of the tables have defaults in date fields and binary(8) fields (@@dbts+1) to support sync / replication. We were considering lingToSql, but i fought hard for ef4 since i feel it's strategically the best long term direction on the MS data platform. I won, and now look like and idiot. This is killing us (me). Please consider releasing this asap. Please?
Posted by bap3 on 8/22/2010 at 8:36 AM
I too need this fix! Every time I update my model from the database i have to manully fix up >40 tables with this attribute! The maintenance along with the possiblilty of losing data makes this a nightmare! Please provide a status as to when the update will be released. Thank you!
Posted by markoh1980 on 8/19/2010 at 8:13 AM
Certainly this isn't fixed and it hurts so badly that I just cannot describe. This is so detering to use the EF. We too are considering ditching the EF and going with something else. Manually editing XML files is nonsense but we would deal with it if it would meant that we only do it once but every single time (after each update)??
Posted by Noam Ben-Ami - MSFT1 on 7/28/2010 at 1:27 PM
The designer team has fixed the issue post-Visual Studio 2010. It will be released as soon as is physically possible.
Posted by Brian Lagunas on 7/21/2010 at 2:49 PM
Any update on this? When will there be a fix?
Posted by Piotr Kowalski1 on 7/15/2010 at 9:07 AM
It's hard to belive that such a bug still remains unresolved...
I am a sincere enthusiast of EF and spend a lot of time trying to engage it in very compilcated, data-intense project. There are many database triggers involved in computing numerous values with crucial importance for application logic. With this bug those computed values are not propagated back to application what results in a predictable manner....
Of course, It's possible to write a stored procedure for each table's update operation that will fetch proper data, but i'm not interested in such 'workaround' at all.
What strengthens my frustration is the fact that this particular bug seems to be easy to fix...
I expect more focus put on MS flagship data-access technology!
Posted by kenb111111 on 7/13/2010 at 11:26 AM
Any word when we might see a patch?
Posted by jvrobert on 7/9/2010 at 1:09 PM
Yeah, this is pretty obnoxious. I have to go in and edit the edmx file every time I update from the DB.
Posted by stealthkrk on 7/3/2010 at 4:42 PM
July 3rd, 2010 - This bug is most certainly not fixed. I am experiencing it NOW. Please address this ASAP! How annoying!
Posted by Joel-MMCC on 11/2/2009 at 2:00 PM
I should also point out that the LINQ-to-SQL .dbml Visual Designer has an “Auto-Sync” property (much easier-to-understand property name) with values of “None,” “OnInsert” (equivalent to “Identity”), “OnUpdate”, and “Always” (not sure which of those last two would be equivalent to “Computed” but I suspect “Always” — again, those are much easier-to-understand property value names) and has had since VS2008 if not VS2005 SP1 and even VS Express 2005! And theirs works!

Are you going to let the LINQ-to-SQL team beat your Entity Framework team this badly? If they could do it more than two years ago, why can’t you do it now?

If saving Entity Framework’s, Visual Studio 2010’s and Microsoft’s reputations from the metaphorical black eyes that the consequences of the widespread data loss and corruption that your team’s refusal to implement such a simple feature is likely to cause isn’t enough motivation for you, how about simple pride in your team’s work and internal division competitiveness?

Already, partly because of this, we’ve made the decision to switch from Entity Framework to LINQ-to-SQL for a major development project. We had already done much work in EF, but we’re tossing it all and going with LINQ-to-SQL instead because of your answer, which, we feel, indicates a lack of competence, vision, and initiative on the part of the EF team. It’s too late for you to salvage it for this particular project, but if you want it to be taken seriously by others for future projects, this must be done, and in the release version of 2010. Not later.
Posted by Joel-MMCC on 11/2/2009 at 1:39 PM
Well, that explains why it appears under “Database Script Generation” in the Properties window, but I submit that its presence there is dangerously confusing, giving developers a false and misleading sense of security — especially since the consequences of not properly setting the “StoreGeneratedPattern” property in the SSDL can easily result in outright (and irreversible) data corruption!

We would all be better off if you removed the feature entirely, and required developers to insert the attribute manually (via XML Editor) in both places as needed. If you don’t have time to add a simple property that inserts one attribute into the SSDL of the field (and I really can’t imagine this being all that hard for you), then remove it entirely. As it is now, this ½way implementation is very, very dangerous, far worse than it being completely absent (as it was in VS2008)!

Fortunately, it was only test data that I lost, but it could just as easily have been the real thing.

Of course, the best solution is simply to add another Property (same name, different grouping) that sets in conjunction with the existing CDSL-setting “Database Script Generation”-group property setting, so that you give the developers a way to more easily set this very common and very critical property. How many database tables do you think have a “Created” or other Default-valued column that isn’t an Identity key column? I’ve not yet tested it on a uniqueidentifier column with Default value set to NewID() or NewSequentialID(), but it seems likely that it would fail to auto-create an SSDL StoreGeneratedPattern="Identity" on that as well — yet such columns used with NewID() is considered a Best Practice!

Do try to imagine this from the PoV of a developer who’s not as familiar with how y’all do things as y’all are. What would such a developer logically infer from seeing a Property named “StoreGeneratedPattern” with possible values of “Identity” and “Computed”? Especially given the help text that displays: “Determines if the corresponding column in the database will be auto-generated during insert and update operations”? What would be the logical inference?
Posted by Microsoft on 11/2/2009 at 10:44 AM
Thank you for filing this bug. We have a work item to make the feature work the way you desire, but cannot fit it into Visual Studio 2010 - it will have to wait for a future release. For now, the feature's intent is only to support generation of databases from the model.
Posted by Microsoft on 10/29/2009 at 5:10 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(