LINQ to Entities无法识别方法'Int32 IndexOf(System.String,System.StringComparison)'方法

时间:2014-04-22 06:12:03

标签: c# .net linq entity-framework

我使用下面的实体框架

执行了linq查询
GroupMaster getGroup = null;
getGroup = DataContext.Groups.FirstOrDefault(item => keyword.IndexOf(item.Keywords,StringComparison.OrdinalIgnoreCase)>=0 && item.IsEnabled)

执行此方法时,我得到如下的异常

  

LINQ to Entities无法识别方法'Int32 IndexOf(System.String,System.StringComparison)'方法,而这个   方法无法转换为商店表达式。

默认情况下包含()方法区分大小写,所以我需要再次转换为lower。是否有任何方法可以检查除contains方法之外的字符串匹配,是否有任何方法可以解决indexOf方法问题?

4 个答案:

答案 0 :(得分:6)

这里你真的只有四种选择。

  1. 全局更改数据库的排序规则。这可以通过多种方式完成,简单的谷歌搜索应该揭示它们。
  2. 更改各个表或列的排序规则。
  3. 使用存储过程并在查询中指定COLATE语句
  4. 执行查询并返回大量结果,然后使用Linq to Objects在内存中进行过滤。
  5. 除非结果集非常小,否则数字4不是一个好的选择。如果你不能改变数据库(但你不能使用Linq),#3是好的。

    数字1和2是您需要对整个数据模型做出的选择,或者您只想在特定字段上进行选择。

    更改服务器排序规则: http://technet.microsoft.com/en-us/library/ms179254.aspx

    更改数据库整理: http://technet.microsoft.com/en-us/library/ms179254.aspx

    更改列排序规则: http://technet.microsoft.com/en-us/library/ms190920(v=sql.105).aspx

    在存储过程中使用Collat​​e语句: http://technet.microsoft.com/en-us/library/ms184391.aspx

答案 1 :(得分:5)

实体框架无法识别字符串类的IndexOf方法,请将此函数替换为SQLfunctionCanonical functions

您也可以从herehere

获取帮助

您可以使用以下代码示例:

DataContext.Groups.FirstOrDefault(item => 
    System.Data.Objects.SqlClient.SqlFunctions.CharIndex(item.Keywords, keyword).Value >=0 && item.IsEnabled)

答案 2 :(得分:4)

相反,您可以使用以下方法来降低案例:

var lowerCaseItem = item.ToLower();

如果您的商品属于string类型。然后,这可能会让你通过这个例外。

答案 3 :(得分:1)

Erik Funkenbush'在将其视为数据库问题时,答案是完全有效的。但是如果你想有效地遍历它们,我觉得你需要一个更好的结构来保存有关关键字的数据。

请注意,此答案并非旨在更好,它旨在解决您的数据模型中的问题,而不是让环境适应当前(显然存在缺陷,因为那里你有一个问题)数据模型。

我的主要建议,无论时间限制(我意识到这不是最简单的修复)都会为关键字添加一个单独的表(与其相关类具有多对多关系)。 / p>

[GROUPS] * ------- * [KEYWORD]

这应该允许您搜索关键字,只有然后检索具有与之关联的关键字的项目(基于ID而不是复合字符串)。

int? keywordID = DataContext.Keywords.Where(x => x.Name == keywordFilter).Select(x => x.Id).FirstOrDefault();

if(keywordID != null)
{
    getGroup = DataContext.Groups.FirstOrDefault(group => group.Keywords.Any(kw => kw.Id == keywordID));
}

但是如果在当前项目中不再可能进行此类修复,我完全可以理解。我想提一下,以防将来遇到这个问题,但仍然可以选择改进数据结构。