DevForce 2009: relationship mapping on foreign keys

relationship mapping on foreign keys

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2009
Forum Discription: For .NET 3.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1087
Printed Date: 01-May-2025 at 10:11am

Topic: relationship mapping on foreign keys

Posted By: egoren
Subject: relationship mapping on foreign keys
Date Posted: 09-Feb-2009 at 2:37pm

Hi,

We are having a problem with DevForce EF.

We have the following database schema:
Person { *PersonId }
Employee { *PersonId, *OrganizationId, PositionId }
Position { *PositionId, *OrganizationId }
[The * represents the primary key(s)]
When adding the table in the ebmx diagram, the relation between Employee and Position is not created and we receive this error :
warning 6030: The relationship 'FK_Employee_Position' uses the set of foreign keys '{OrganizationId, PositionId}' that are partially contained in the set of primary keys '{OrganizationId, PersonId}' of the table 'Employee'. The set of foreign keys must be fully contained in the set of primary keys, or fully not contained in the set of primary keys to be mapped to a model.

Is there a way to create this relation in DevForce EF like we could (and do) in DevForce Classic?

Replies:

Posted By: kimj
Date Posted: 10-Feb-2009 at 12:01pm

First I should say that because DevForce EF uses the ADO.NET Entity Framework for the underlying entity model that we're dependent on the rules enforced by EF, which are in general somewhat strict. What you're seeing here is a message from EF as you build your model via the Entity Data Model designer, so the error itself is not raised by DevForce.

Apparently this error is a known limitation in EF - here's what a Microsoft engineer said on the ADO.NET EF forum:

Yes, this is a restriction of the current version of the EF: It does not allow foreign keys which are only partly inside of the primary key. It is not a limitation of the tools, but of the framework itself."

In your situation I don't know if it would make sense to a) not mark the Employee.OrganizationId as part of the primary key, or b) add OrganizationId to the Person table, or c) add surrogate keys to these tables, or d) leave the association unmapped.