CODEWITHSUNDEEP
entity-frameworkentity-framework-4poco
kdawg
kdawg

Reputation: 2009

Entity Framework 4 -- Problems with ExecuteFunction<T> of FunctionImport mapped to POCO Complex Type

I am receiving an error when trying to execute a FunctionImport -- result is mapped to a POCO ComplexType -- from within a custom ObjectContext. Specifically, the error states:

The type parameter BlahComplexType in ExecuteFunction is incompatible with the type BlahComplexType returned by the function.

Because I'm using a custom ObjectContext (I'm working with a fully POCO Entity Framework environment), I must call the FunctionImport manually, which I do like:

var blah = ExecuteFunction<BlahComplexType>("GetBlah", MergeOption.NoTracking,
            new ObjectParameter("p_one", paramOne),
            new ObjectParameter("p_two", paramTwo),
            new ObjectParameter("p_three", string.Empty));

I am not using any T4 templates to generate POCOs, all classes are manually written. BlahComplexType is a class with simple data type properties. Its definition matches the ComplexType definition in the .edmx file, including matching namespaces and everything (I've got plenty of other Entities and Complex Types mapped to POCOs, as well).

The msdn documentation states here that the return type of ExecuteFunction<T> must implement IEntityWithChangeTracker, but isn't the whole point of mapping to a ComplexType instead of an Entity is precisely because I don't care about any changes (in fact, changes are not allowed -- BlahComplexType is considered a "Value Object")?

Has anyone had any luck calling a FunctionImport with ExecuteFunction whose results are mapped to a POCO ComplexType with Entity Framework 4?

Upvotes: 3

Views: 8869

Answers (1)

kdawg
kdawg

Reputation: 2009

Wow, stupid user error!!

As always with manual creation of the POCO classes -- it was an inconsistency between the ComplexType definition in the EDMX file and its POCO class. If there's just one error or inconsistency, then the error message makes an attempt at telling you the source of the problem. However, if you have more than one, it'll just state that the types are "incompatible", so you're left wondering.

In my case, I had both a property name inconsistency (one had "AcctId", the other had "Acctid") and a property data inconsistency (class was expecting int (Int32) but the stored procedure returned Int16).

So, as always, double and triple check EDMX definition and POCO class definition. (I double checked, but neglected to triple check!!)

facepalm

Upvotes: 6

Related Questions