views:

567

answers:

1

I've got a pretty large DB hooked up to my Entity Framework. I've got one particular set of tables where a common key (fk) was deleted from the design. When I "update the model from the database", I get a series of errors about this now-missing key.

Why doesn't the update process accurately detect that this key was removed? Also, if I manually remove the property from the model, I just end up with other errors. I also tried to simply delete the table and re-add it, but now the table doesn't show up in the "Add" section of the update wizard.

So, short of deleting the entire thing and starting over, is there any way to recover gracefully? Has the EF team released any newer versions of this wizard that has some of these issues fixed in it already?

+3  A: 

Entity Framework does get confused from time to time. What you need to do is delete the Entity Table from the model, then rename the table in SQL Server to TableName_Temp, refresh the model, now the Entity Table should be OK, so delete the entity table again rename it back to the original name and refresh the model once more. This time everything should be fine.

I know this is a messed up procedure but this is the only way I found to fix this issue without blowing away the entire edmx and starting from scratch. Currently at my organization we have a policy not to make changes to the EDMX unless absolutely necessary so that we can delete and recreate when ever needed without any problems.

Hope this helps!

Lukasz
Isn't that a sad commentary on the regen process? The rule in the company is to simply not allow edmx change? MS should really address this pain point for people.
Jason Short
I believe that they are addressing most of the pain points with LINQ to SQL and LINQ to Entities in the 4.0 release. They even offer a mode where you don't even need an EDMX file. I am not sure how fully featured that mode is but it could provide for a cleaner implementation than NHibernate does if you don't use the Fluent mapping.
Lukasz