LINQ to SQL查询基于使用外键还是使用内置导航属性而成功或失败

Question

I have a query against a SQL server database that throws an Error converting data type nvarchar to numeric. exception. I was trying to use Convert.ToDecimal on a varchar field, however I'll eyeballed the data as best I could and couldn't find an invalid value.

The query is filtering the table by a 'Group' by using the foreign key of p.pgKey=# . However, if I use the navigation property and filter by the navigation property instead, p.Group.gName='ABC' the query works.

Here are the queries (note, originally, I didn't know if error was happening in Where translation or the Select processing, so that is why query looks weird, but as you can guess, when it works, it should just return a single distinct row of true ):

Profiles
    .Where(p =>
       p.pgKey == 237
       && !p.pPlanProfile.Value
      && Convert.ToDecimal(p.pSearch08 ?? "0") > 0
    ).Select(p =>
       Convert.ToDecimal(p.pSearch08 ?? "0") > 0
    )
    .Distinct()
    .Dump();

The above query fails, while this query succeeds:

Profiles
    .Where(p =>
       p.Groups.gName == "ABC"
       && !p.pPlanProfile.Value
       && Convert.ToDecimal(p.pSearch08 ?? "0") > 0
    ).Select(p =>
       Convert.ToDecimal(p.pSearch08 ?? "0") > 0
    )
    .Distinct()
    .Dump();

Below is a full LINQPad screen dump showing:

1. Proves the gKey for ABC is 237.
2. Proves that the counts of simplying counting the Profile records is identical when using pgKey or Group.gName .
3. Shows the query working correctly when using the Group.gName processing.
4. Shows the query failing when using the pgKey processing.

Obviously I've used the Group.gName method to fix my problem, but I stumbled on that solution by accident. Anyone know why LINQ to SQL would behave this way?

Note : I get the same behavior using the generated DataContext from LINQPad or if I run against a compiled .dbml DataContext.

Answer 1

The two queries will be generating different TSQL and hence the query plan will be different.

I would suspect that the former query is attempting to convert some values of pSearch08 to decimal before it rejects them based on the other selection criteria, whereas the latter query is performing the other selection criteria first and hence is attempting to convert a smaller number of pSearch08 values to decimal and hence does not attempt to convert the invalid value.

If this is the case, then it could be dangerous to assume that the second query will always work and it would be best to fix the invalid data.

Rather than eyeballing the data you can try

SELECT * from Profile where ISNUMERIC(pSearch08) = 0