Scenario: Trying to extract and rearange information from one database to an other. DB A has some data I want to get. I want to store it on DB B in a slightly different structure.
DB A I get using an EDMX database generated model so it uses a derivative of ObjectContext. DB B I would like to be Code generated. So I use the code/model first approach by installing EntityFramework 4.1 via Package manager. So DB B uses a DbContext derivative
When I try to store information from DB A to DB B it's says:
Test method RoutIT.Irma.Import.Service.Test.ImportIrma2ProductTests.ImportProducts threw exception: System.ArgumentException: Could not find the conceptual model type for 'Some entity in DB A's EDMX model'
It actually does it when adding a DB B entity to the DB B's Derived DbContext's DbSet property. So the code is like
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
{
foreach (FirstPVC pvc in pvcs)
{
this._irmaImport.FirstPVCs.Add(pvc); <--
this._irmaImport.SaveChanges();
}
scope.Complete();
}
}
It happens at the point in the code marked by the arrow above ("<--")
FirstPVC is a DB B property yet at the point of the arrow it complanes about not having a conceptual model for an entity belonging to DB B's context.
This is strange since I try to store an DB B entity to the DB B context. Why should it care about entity's of DB A.
All contexts are contained in the same project. But DB B's Derived DbContext only has knowledge about it's own DbSet<> properties, suddenly when trying to add something to the DbSet<> property it give me the error in bold above.
Anybody know why this happens? Why should DbContext care about entity's of another context specifically one of a ObjectContext derived class.
Perhapse it's usefull to note the entity it's complaining about looks a bit like this
[EdmEntityTypeAttribute(NamespaceName="Irma2Model", Name="AccessProvider")]
[Serializable()]
[DataContractAttribute(IsReference=true)]
public partial class AccessProvider : EntityObject
{
/*****...... ******/
}
Found an answer, its not what you want to hear though:
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/d2a07542-cb33-48ba-86ed-4fdc70fb3f1a
"If you are using the default code generation for the EDMX file then the generated classes contain a series of attributes to help EF find which class to use for each entity type. EF currently has a restriction that POCO classes can't be loaded from an assembly that contains classes with the EF attributes. (Short answer is no, your classes need to be in separate projects).
This is a somewhat artificial restriction and something that we realize is painful and will try and remove in the future."
So the workaround would be to split the classes into two different assemblies.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With