none
Only primitive types or enumeration types are supported in this context. RRS feed

  • Question

  • I am trying to get a list of invoices for a customer, each invoice having a customer object

    publicvirtualCustomerCustomer { get; set; }

    I am using EF6.1 and VS2013Express and coding in c#

    I have read the various posts on this but am now more confused than before!!

    My code is

     

    EntityModel.Model.Customer myCust = dbContext.Customers.Find("name"); ;
    var query = (from inv in dbContext.Invoices
                              where inv.Customer== myCust
                              select inv).ToList();

    and it gives the error 'Only primitive types or enumeration types are supported in this context.'

    If I understand the posts this seems to be a problem in EF but there must be a simple workround for this common scenario.

    Advice please


    John Meers

    Monday, November 10, 2014 12:36 PM

Answers

  • Found it.

    You have to specify the primary key in the 'where'

    I am rather surprised I would have thought EF would understand that a primary key identifies an object.

    Nope you didn't find it, and you don't understand what the error message is telling you.

    The link talks about primitive types in .NET, and it doesn't need to be a primary-key of the SQL Server table or within the Entity/object either. Objects have properties, and in this case,  an Entity/object has public properties within the object that hold data that represent the columns in the SQL Server table the object was derived from a bunch of primative type columns in the table that make up the primative-type properties of an Entity/object .

    http://msdn.microsoft.com/en-us/library/aa711900(v=vs.71).aspx

    What you were trying to do with a Where clause was take two objects and compare them instand of going to the primative-type properties of each object and making the comparision between the primative-type properties of the Entity/object.

    var query = (from inv in dbContext.Invoices
                              where inv.Customer.Status == myCust.Status
                              select inv).ToList();

    It would have  worked, becuase you are comparing the two primative-type properties within each object instead trying to compare each object with each other as a whole.

    • Marked as answer by JohnMeers Monday, November 10, 2014 5:43 PM
    Monday, November 10, 2014 3:30 PM

All replies

  • Found it.

    You have to specify the primary key in the 'where'

    I am rather surprised I would have thought EF would understand that a primary key identifies an object.


    John Meers

    Monday, November 10, 2014 12:48 PM
  • Entity Framework cannot translate the equality operator for a custom reference type like your Customer class. The  Invoice entity should have a scalar foreign key property (called something like CustomerId = foreign key association) of a primitive type (like for example int) that specifies the primary key of which customer it belongs to:

    var query = (from inv in dbContext.Invoices
                               where inv.CustomerId == myCust.Id
                               select inv).ToList(); 

    Please refer to the following page for more information:
    http://msdn.microsoft.com/en-us/data/jj713564.aspx
    http://msdn.microsoft.com/en-us/library/vstudio/ee828425(v=vs.100).aspx

    Please remember to mark helpful posts as answer and/or helpful.

    Monday, November 10, 2014 2:14 PM
  • Found it.

    You have to specify the primary key in the 'where'

    I am rather surprised I would have thought EF would understand that a primary key identifies an object.

    Nope you didn't find it, and you don't understand what the error message is telling you.

    The link talks about primitive types in .NET, and it doesn't need to be a primary-key of the SQL Server table or within the Entity/object either. Objects have properties, and in this case,  an Entity/object has public properties within the object that hold data that represent the columns in the SQL Server table the object was derived from a bunch of primative type columns in the table that make up the primative-type properties of an Entity/object .

    http://msdn.microsoft.com/en-us/library/aa711900(v=vs.71).aspx

    What you were trying to do with a Where clause was take two objects and compare them instand of going to the primative-type properties of each object and making the comparision between the primative-type properties of the Entity/object.

    var query = (from inv in dbContext.Invoices
                              where inv.Customer.Status == myCust.Status
                              select inv).ToList();

    It would have  worked, becuase you are comparing the two primative-type properties within each object instead trying to compare each object with each other as a whole.

    • Marked as answer by JohnMeers Monday, November 10, 2014 5:43 PM
    Monday, November 10, 2014 3:30 PM
  • Thanks, that has cleared it up for me.  I did appreciate that properties are needed (eventually) but wondered why EF LINQ did not use the primary key by default.

    If I had implemented IComparable<> on the Customer object would that have worked.  Seems a bit cleaner to me.

    John


    John Meers

    Monday, November 10, 2014 4:24 PM
  • Thanks, that has cleared it up for me.  I did appreciate that properties are needed (eventually) but wondered why EF LINQ did not use the primary key by default.

    If I had implemented IComparable<> on the Customer object would that have worked.  Seems a bit cleaner to me.

    You are talking Linq query here man,  and you need to understand Linq, which generates T-SQL to query the database table that brings back/materalizes a single object, or it brings back/materalizes a collection of objects in a tubular form in a List<T>.

    Maybe, the two links will help you.

    https://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b

    http://www.linqpad.net/

     

    Monday, November 10, 2014 4:44 PM
  • Thanks I will have a read.

    I learned coding back in the 1960's and then shifted to manager, so you can guess the mindset changes needed.  We would have given our eyeteeth back then for some of this.

    However the idea of EF (and LINQ?) is to hide the database isn't it so my expectations have some merit, I have also run into trouble with LINQ with fields marked as [Not mapped] and can now see why

    Your help is very much appreciated but I think it fair to mark this as answered, I have learned a lot more than just the one answer!!


    John Meers

    Monday, November 10, 2014 5:43 PM