Скомпилированная проблема Запроса LINQ-SQL (работает нескомпилированным запросом),

Если Вам установили жемчуг, то perl -i -n -e"print unless m{(ERROR|REFERENCE)}" должен добиться цели.

8
задан 12 revs, 3 users 100% 9 August 2010 в 07:32
поделиться

1 ответ

I believe the compiled query must be translatable to SQL, which your extension method cannot be. If you profile the SQL created by your "regular" query you may find it is selecting the entire table so it can feed all the rows into your extension method.

You'd do better to put your filtering logic in the query (as part of the expression tree) so it can be translated to SQL and run server side.

The OrderBy is also a problem because of the Skip. You need to make this translatable to SQL or LINQ will have to return all the rows in order to filter them down client side.

If you can't express these as LINQ expressions, consider creating SQL Functions on the server and mapping them to your DataContext. LINQ will be able to translate those to the T-SQL function calls.

EDIT:

I guess I was assuming your extension methods weren't building expression trees. Sorry.

Consider this link which seems similiar to your problem. It references another link that goes into more detail.

It looks like the MethodCallExpression is the issue.

The code is a bit long to be posted здесь, но аналогично tomasp.net расширитель, я посещаю каждое выражение в дерево выражения, и если узел выражение MethodCallExpression, которое вызывает метод, который возвращает выражение дерево, я заменяю это MethodCallExpression выражением дерево, возвращаемое при вызове метода.

Итак, похоже, проблема в том, что при компиляции запроса метод не выполняется, поэтому нет дерева выражений для преобразования в SQL.

3
ответ дан 6 December 2019 в 00:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: