Accepted answer

the difference is that in the first case, var will be an iqueryable<t> - which means your where call will be to queryable.where (after converting your lambda expression to an expression tree). the filter ends up being executed in the database, where i suspect your field is case-insensitive (and so searching is case-insensitive).

in the second case, you've got an ienumerable<t>, so your where call will be to enumerable.where (after converting your lambda expression to a delegate). the filter ends up being executed in .net code instead - where contains is always case-sensitive.

basically, linq is a leaky abstraction - yes, it would be lovely if the same filter gave the same results in all situations, but that's unrealistic. learn where the leaks are, and act accordingly - linq is still a huge boon :)


your result variable is not an ienumerable - it is an iqueryable.

the result is changing when you manually change the type to ienumerablesince you now do the following contains query with linq to objects and not on the database with linq to entities (or linq to sql).

with ienumerable your query is using your lambda expression, bringing each result from the db into memory and executing the case sensitive contains() extension method.

with iqueryable your query is using an expression tree and will try to create a corresponding database query with your contains query which happens to be case insensitive (most likely a sql like query).

just making the implicit type explicit as iqueryable will fix your problem.

Related Query

More Query from same tag