Entity Framework 4.0 foreign keys problem in mapping fragments

  • Thread starter Thread starter jeff413
  • Start date Start date
J

jeff413

I am using the Microsoft AdventureWorks2008 sample database and trying to
create an EF EDMX model so I can try EF out. Whenever I try to add
ProductModel or ProductSubCategory tables to model and have EF associate
either of these tables with the Product table I get an error like the
following:

Error 1 Error 3007: Problem in mapping fragments starting at lines 488,
535:Column(s) [ProductSubcategoryID] are being mapped in both fragments to
different conceptual side properties.
C:\Users\Owner\Documents\Visual Studio
10\Projects\EntityFramework\AdventureWorks.Data\AdventureWorksDBFirst.edmx 536 11 AdventureWorks.Data

I have tried hand editing the edmx and renaming or deleting the association.
This always seems to result in more errors for me. The only thing that
works is physically deleting the foreign key from database and refreshing the
model but then I don't have a navigation property between the entities.

Can someone please explain what this error means and how I can get around it?
 
I was able to answer my own question eventually. My original description of
problem didn't have details quite right.

To reproduce: In AdventureWorks 2008 add the Product and ProductSubcategory
tables to model.

Save and build solution. No errors.

Then add the ProductCategory table to model.

Save and build solution, you will get error:

Error 3007: Problem in mapping fragments starting at lines 199,
222:Column(s) [ProductCategoryID] are being mapped in both fragments to
different conceptual side properties.

To fix the error delete the ProductCategoryId property from the
ProductSubcategory entity in the conceptual model either from the designer or
in the EDMX. Since ProductSubcategory has a ProductCategory navigation
property it can’t also have ProductCategoryId as a property in the conceptual
model.

If you add all 3 tables at once you don't get the error.

If you are adding tables incrementally to a model you will eventually hit
this error. It wasn't obvious to me what the heck was wrong. Now I know.

I think the problem is that while the Storage model can be refreshed the
conceptual model is left alone by designer when doing updates(a good thing in
most cases so you don't lose your custom changes). It might be nice to have
"repair" option to refresh the Conceptual-Side from the designer but maybe
that introduces other problems.
 
If you are adding tables incrementally to a model you will eventually
hit this error. It wasn't obvious to me what the heck was wrong. Now
I know.
Click to expand...

In Entity Framework, relationships are an object. One of the downsides
to this way of looking at relationships is you can end up adding
something that keys to something you have not added to the model.

I am not sure I like the methodology, but it sure makes it easy to have
joins on multiple fields, so it is certainly more flexible. I am not
sure if that was the primary reason for the methodology, just an
observation of one benefit.

One downside to the EF model, at least prior to the POCO addition, is
the amount of overhead you add for programmers that consume your models
on other platforms. It prevented me from using EF on a cross platform
web service. I have not played extensively with the POCO implementation,
but it should solve my issue.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Back
Top