Accepted answer

it filters in the database since your building your expression atop of an itable returning a iqueryable<t> data source.


these folks are right and one recommendation i would have is to monitor the queries that linqtosql is creating. linqtosql is a great tool but it's not perfect. i've noticed a number of little inefficiencies by monitoring the queries that it creates and tweaking it a bit where needed.

the datacontext has a "log" property that you can work with to view the queries created. i created a simple httpmodule that outputs the datacontext's log (formatted for sweetness) to my output window. that way i can see the sql it used and adjust if need be. it's been worth its weight in gold.

side note - i don't mean to be negative about the sql that linqtosql creates as it's very good and efficient almost every time. another good side effect of monitoring the queries is you can show your friends that are die-hard - stored proc people how efficient linqtosql really is.


linq to sql translates your query into sql before sending it to the database, so only the filtered list is returned.


when the query is executed it will create sql to return the filtered set only.

one thing to be aware of is that if you do nothing with the results of that query nothing will be queried at all.

the query will be deferred until you enumerate the result set.

Related Query

More Query from same tag