This bug is related to the bug [#1385](https://entityframework.codeplex.com/workitem/1385) (that it is fixed in EF6rc1 for the scenario provided).
Although the issue is fixed for the scenario I posted in the previous bug, when I tried to use EF6rc1 in my real domain I got almost the same error.
> (34,6) : error 3018: Problem in mapping fragments starting at line 34:Foreign key constraint 'Itinerary_Addresses_Target' from table ItineraryAddress (Address_Id) to table Address (Id): The columns of table ItineraryAddress are mapped to AssociationSet Itinerary_Addresses's End Itinerary_Addresses_Target but the key columns of table Address are not mapped to the keys of the EntitySet Addresses corresponding to this End.
I was able to reproduce the issue by extending a bit the provided scenario, here is the code: https://github.com/jorgef/tablesplitting
The scenario now has an extra entity called Account that has a reference to User:
```
public class Account
{
public int Id { get; set; }
public User User { get; set; }
}
```
I have cloned the EF6's source code and debugging it __I found the root of the problem__.
It looks like with EF6 the model (edmx) is generated properly but __there is a validation that is not properly supporting table splitting__.
The method __FindEntitySetForColumnsMappedToEntityKeys__ located in the class System.Data.Entity.Core.Mapping.ViewGeneration.Validation.__ForeignConstraint__ tries to find the right EntitySet for a given set of columns (key) but it doesn't take in account the fact that when using table splitting we have two EntitySets mapped to the same table using the same columns as key. So this method will always return the first EntitySet found, not matter if there are more than one.
So, __if you are unlucky enough to have your EntitySets in the not expected order in the "cells" collection, then it will return the wrong EntitySet and therefore an error will be raised by the caller__ (ForeignConstraint.CheckParentColumnsForForeignKey()).
As the list of EntitySets is generated by discovering entities/properties, adding a new Entity that starts with A (Account) with a relationship to the User entity made the trick to change the order of the EntitySets and therefore reproduce the bug (it puts User before Address).
By downloading the source code from https://github.com/jorgef/tablesplitting and pressing F5 you should be able to repro the problem.
If you have any questions, please let me know, I have spent a few hours debugging and understanding the problem so I can give you more context if it is needed.
Although the issue is fixed for the scenario I posted in the previous bug, when I tried to use EF6rc1 in my real domain I got almost the same error.
> (34,6) : error 3018: Problem in mapping fragments starting at line 34:Foreign key constraint 'Itinerary_Addresses_Target' from table ItineraryAddress (Address_Id) to table Address (Id): The columns of table ItineraryAddress are mapped to AssociationSet Itinerary_Addresses's End Itinerary_Addresses_Target but the key columns of table Address are not mapped to the keys of the EntitySet Addresses corresponding to this End.
I was able to reproduce the issue by extending a bit the provided scenario, here is the code: https://github.com/jorgef/tablesplitting
The scenario now has an extra entity called Account that has a reference to User:
```
public class Account
{
public int Id { get; set; }
public User User { get; set; }
}
```
I have cloned the EF6's source code and debugging it __I found the root of the problem__.
It looks like with EF6 the model (edmx) is generated properly but __there is a validation that is not properly supporting table splitting__.
The method __FindEntitySetForColumnsMappedToEntityKeys__ located in the class System.Data.Entity.Core.Mapping.ViewGeneration.Validation.__ForeignConstraint__ tries to find the right EntitySet for a given set of columns (key) but it doesn't take in account the fact that when using table splitting we have two EntitySets mapped to the same table using the same columns as key. So this method will always return the first EntitySet found, not matter if there are more than one.
So, __if you are unlucky enough to have your EntitySets in the not expected order in the "cells" collection, then it will return the wrong EntitySet and therefore an error will be raised by the caller__ (ForeignConstraint.CheckParentColumnsForForeignKey()).
As the list of EntitySets is generated by discovering entities/properties, adding a new Entity that starts with A (Account) with a relationship to the User entity made the trick to change the order of the EntitySets and therefore reproduce the bug (it puts User before Address).
By downloading the source code from https://github.com/jorgef/tablesplitting and pressing F5 you should be able to repro the problem.
If you have any questions, please let me know, I have spent a few hours debugging and understanding the problem so I can give you more context if it is needed.