CODEWITHSUNDEEP
.netentity-framework
Craig W.
Craig W.

Reputation: 18165

The type parameter 'POCO Class' in ExecuteFunction is incompatible with the type 'EFComplexType' returned by the function

We've got an EF model that's using POCO generation for its types. We added a stored procedure and created a function import for it. We then generated a Complex Type for the result set and let the T4 template generate the business contract (POCO).

Everything works great in our development, devint, and QA environments. When we deploy to production the application works for a while and then starts throwing this exception:

System.InvalidOperationException: The type parameter 'POCO' in ExecuteFunction is incompatible with the type 'EFComplexType' returned by the function.

If we recycle the application pool the exception goes away for a little while and then comes back, so we recycle the app pool again, and so on...

We have been unable to reproduce the problem in any environment other than production which is making it very hard to determine the root cause.

I doubt anyone has a pat answer to this, but any thoughts as to what it might be, areas we might want to explore, or thoughts on tracking down the root cause would be helpful.

Upvotes: 3

Views: 3287

Answers (3)

clamum
clamum

Reputation: 1364

I know you already have an answer here but I figured I'd add one because my solution was different and while my case is probably not that common, it hopefully might help one person from pulling out their hair.

I had to add a stored procedure manually to the Entity Framework model (DataModel.Content.cs, DataModel.edmx, then the SprocName_Result.cs file) because for some reason I cannot use the UI within Visual Studio to update the Data Model. I've ran into this before so it's not something I haven't done before.

However the reason for this exception in my case was because there were mismatches between the data types listed for table columns in the SprocName_Result.cs class and the actual database column data types in SQL Server. I had to go down each table column that made up the sproc result set and compare data type and nullable to what was in the SprocName_Result.cs (and also the DataModel.edmx entries as well). Once I fixed the data types and nullable states, so they matched between what exists in SQL Server and what the Data Model files said, it worked.

Upvotes: 0

Craig W.
Craig W.

Reputation: 18165

We finally figured out what was causing the problem. We had another service that was also using EF. It was using the ExecuteStoreQuery method that hangs off the ObjectContext. As soon as that method was called all of our other EF queries started to fail with either the above message or an "incompatible metadata" message. We rewrote that query to use standard ADO.NET and haven't had a problem since.

Upvotes: 2

Slappy
Slappy

Reputation: 4092

Firstly there is the immediate checks. Are your procs the same between dev and production?

Are you using the latest version of the POCO T4 Template, I have found a few bugs in it before.

The Dev to Deploy scenario crops up a lot with EF. First thing to check: Dev Environment is SQL 2008, production is SQL 2005. EF really hassles with this. You need to generate your model on the DB version you are using. Start with that.

The fact that recycling the app pool helps, might point to some form of caching or context retention. Check that your objects scope doesn't live on between requests. If you running a singleton pattern somewhere this is a prime suspect.

Are you dynamically loading assemblies at all?

Would it be possible to post the generated function call code from the datacontext?

Upvotes: 0

Related Questions