Using Both ObjectContext and DbContext
Asked Answered
C

1

6

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
{
    /*****...... ******/
}
Cotemporary answered 10/8, 2011 at 21:55 Comment(2)
I think I have the same problem. I had two DB-first EDMXs mapping different tables from the same DB and now I've switched one of them to the newer EF4.1 DbContext/POCO model. Yet when I try and use the latter, I get an error about an missing model for a table in the other EDMX. Maybe this answer is relevant?: #3521997 . Note I think you have a typo in your post "it complains about not having a conceptual model for an entity belonging to DB B's context", you mean DB A right?Colliery
#6900067 this too. No answer thoughColliery
C
6

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.

Colliery answered 12/8, 2011 at 15:25 Comment(1)
Thanks for jumping in the fire on this one. You just saved ME a couple of hours. I was wanting to separate the edmx classes into a separate assembly anyhow. You gotta wonder what kind of overhead is being created under the covers with EF. Seriously thinking about nhibernate next round!Kacikacie

© 2022 - 2024 — McMap. All rights reserved.