Why does this Entity Framework LINQ query fail?

Question

I have a simple EF Linq query that used to work. Now it is returning null every time and I can't track down why.

public Sample GetDataSample(Equipment equip)
{
    Sample sample = null;
    try
    {
        sample = this.Samples.FirstOrDefault(s => s.EquipmentId == equip.Id);
    }
    catch (Exception e)
    {
        // do nothing for now
    }
    return sample;
}

This is called from within an active DbContext with a valid Equipment entity. Here is what I am seeing in the debugger. I have verified that the DbSet Samples in the active context does contain data that should match. Please tell me I am missing something obvious.

EDIT: I did a LINQ profile to see what the SQL generated was and it looks fine:

SELECT TOP (1) 
[Extent1].[Id] AS [Id], 
[Extent1].[EquipmentId] AS [EquipmentId], 
[Extent1].[SampleTime] AS [SampleTime]
FROM [Pbhs].[Samples] AS [Extent1]
WHERE [Extent1].[EquipmentId] = 1

Now, I am wondering if the EF lookup is checking the local proxy or if it is looking in the database. The data exists in the current context but has not been committed to the database yet.

Yes, this is a new project based on an existing project. But this part of the code has not been changed. Given the context, I see no reason why this query should return null. — Psyfun, Jul 29 '15 at 15:47
Can you use SQL Profiler to check which SQL statement EF generates? — Thiago Custodio, Jul 29 '15 at 16:02
Has the backing store changed? Are you pointing to the same database? FirstOrDefault, as its name implies, returns null if there's nothing that matches its predicate. — Jerry Federspiel, Jul 29 '15 at 18:11
No, the store hasn't changed. All the operations occur within the same `DbContext`. As you can see in the debugger, the data is there and the proxies exist in the context, it just isn't finding them. — Psyfun, Jul 29 '15 at 18:16
Have you run the sql against the db to see if it returns any records? The data may not exist in the db. — moarboilerplate, Jul 29 '15 at 18:22
I suspect if you say sample = this.Samples.Local.FirstOrDefault(s => s.EquipmentId == equip.Id); you will get the result you're expecting. The query as you've stated it is just checking the DB and won't find anything prior to SaveChanges() being called. See http://stackoverflow.com/questions/6426053/why-do-entity-framework-queries-not-return-unsaved-entities — Jerry Federspiel, Jul 29 '15 at 18:29
^this, and I'm confused as to what you are trying to accomplish here. I see a DataSamples property on the object in question, and it is populated. Why not reference that instead of using your method? — moarboilerplate, Jul 29 '15 at 18:30
The goal is to add samples without duplication. As samples are added, a query determines if a given sample already exists in the database. Or in this case already exists in the local unsaved `DbSet` or the database. So, I guess I will need to check both the local context and the database to cover all bases. — Psyfun, Jul 29 '15 at 18:37
@moarboilerplate, I think you are right, it might be easier to use the DataSamples property. As long as the object doesn't leave the context, it should stay in sync as new samples are added. — Psyfun, Jul 29 '15 at 18:43

score 1 · Answer 1 · answered Jul 29 '15 at 18:47

1

There are two things here:

 s.EquipmentId == equip.Id

How is an equipment Id, "EquipmentId" the same as a primary key Id? Are you sure you are not comparing "apples" to "oranges"?

The data exists in the current context but has not been committed to the database yet.

Then searching on Id will fail because the new item has not been committed to the database and assigned an Id.

answered Jul 29 '15 at 18:47

ΩmegaMan

29,542
12
100
122

I am sure that we are not comparing apples to oranges and that the fields reference one another. The problem did indeed end up being that the data hadn't been committed yet as pointed out by Jerry Federspiel above. – Psyfun Jul 29 '15 at 19:02

Why does this Entity Framework LINQ query fail?

1 Answers1