代码之家  ›  专栏  ›  技术社区  ›  Raul Agrait

where表达式中的SQL server忽略大小写

  •  76
  • Raul Agrait  · 技术社区  · 17 年前

    SELECT * FROM myTable WHERE myField = 'sOmeVal'
    

    7 回复  |  直到 7 年前
        1
  •  146
  •   Adam Robinson    17 年前

    在SQL Server数据库的默认配置中,字符串比较 不区分大小写。如果数据库覆盖此设置(通过使用备用排序规则),则需要指定在查询中使用哪种排序规则。

    SELECT * FROM myTable WHERE myField = 'sOmeVal' COLLATE SQL_Latin1_General_CP1_CI_AS
    

    请注意,我提供的排序规则只是一个示例(尽管它很可能对您很有用)。可以找到更全面的SQL Server排序规则概述 here .

        2
  •  30
  •   Andrejs Cainikovs    17 年前

    通常,字符串比较不区分大小写。如果数据库配置为区分大小写的排序规则,则需要强制使用不区分大小写的排序规则:

    SELECT balance FROM people WHERE email = 'billg@microsoft.com'
      COLLATE SQL_Latin1_General_CP1_CI_AS 
    
        3
  •  23
  •   Danny    16 年前

    upper(@yourString)
    

        4
  •  22
  •   Solomon Rutzky    7 年前

    前两个答案(来自 Adam Robinson Andrejs Cainikovs )它们在技术上确实有效,但它们的解释是错误的,因此在许多情况下可能会产生误导。例如 SQL_Latin1_General_CP1_CI_AS 排序规则在许多情况下都会起作用,不应假定它是适当的不区分大小写的排序规则。事实上,考虑到O.P.在数据库中使用区分大小写(或可能是二进制)的排序规则,我们知道O.P.没有使用默认的排序规则,这是许多安装(尤其是在使用美国英语作为语言的操作系统上安装的任何安装)的默认排序规则: SQL拉丁语通用CP1 CI AS . 当然可以,O.P。 能够 SQL_Latin1_General_CP1_CS_AS ,但在与 VARCHAR 对于数据,不要更改代码页很重要,因为它可能导致数据丢失,这由排序规则的区域/文化控制(即拉丁语、法语、希伯来语等)。请参见下文第9点。

    其他四个答案在不同程度上是错误的。

    1. 不要使用 UPPER() COLLATE 上() 还必须逐个字符检查是否存在大写映射,然后更改它。你需要在两边都这样做。添加 只是指示处理使用与默认情况下不同的一组规则生成排序键。使用 整理 绝对比使用更有效(或者“performant”,如果你喜欢这个词:) 上() 如本文所证明的 test script (on PasteBin) .

      还有一个问题 noted by @Ceisc on @Danny's answer:

      在某些语言中,case转换不是往返的。i、 e.下(x)!=下(上(x))。

      土耳其大写“°”是常见的示例。

    2. 整理 子句(这可能是这个常见错误概念的来源),但它不会直接影响查询,除非您将字符串文本和变量与其他字符串文本和变量进行比较,或者您正在引用数据库级元数据。

    3. 排序规则是 (即某物操作数某物)或表达式,而不是每个查询。这对于整个查询是正确的,而不仅仅是 WHERE 条款这包括联接、分组依据、排序依据、分区依据等。

    4. 不,不要转换为 VARBINARY (例如。 convert(varbinary, myField) = convert(varbinary, 'sOmeVal') )基于以下原因:

      1. 如果确实需要二进制比较,请使用二进制排序规则。使用以 _BIN2 如果您使用的是SQL Server 2008或更高版本,那么除了使用以 _BIN . 如果数据是 NVARCHAR 那么,使用哪种语言环境并不重要,因为在这种情况下,它们都是相同的,因此 Latin1_General_100_BIN2 瓦尔查尔 ,则必须使用数据当前所在的区域设置(例如。 Latin1_General , French , Japanese_XJIS
      2. CONVERT() 它将使用默认值30。危险在于,如果字符串可能超过30字节,它将被自动截断,并且您可能会从该谓词得到不正确的结果。
      3. binary collations are not case-sensitive (另一个非常常见的误解)。
    5. LIKE 不总是区分大小写。它使用被引用列的排序规则,如果将变量与字符串文字进行比较,则使用数据库的排序规则,或者使用通过可选 整理 条款

    6. LCASE 不是SQL Server函数。它似乎是Oracle或MySQL。或者可能是VisualBasic?

    7. 由于问题的上下文是将列与字符串文字进行比较,因此实例的排序规则(通常称为“服务器”)和数据库的排序规则都没有任何区别 直接的 这里的影响。排序规则按每列存储,每列可以有不同的排序规则,并且这些排序规则不需要与数据库的默认排序规则或实例的排序规则相同。当然,如果 整理 创建数据库时未指定子句。同样,如果 整理 未指定子句。

    8. 您应该使用与列的排序规则相同的不区分大小写的排序规则。使用以下查询查找列的排序规则(更改表名和架构名):

      SELECT col.*
      FROM   sys.columns col
      WHERE  col.[object_id] = OBJECT_ID(N'dbo.TableName')
      AND    col.[collation_name] IS NOT NULL;
      

      _CS 成为 _CI . 所以 Latin1_General_100_CS_AS 将成为 Latin1_General_100_CI_AS .

      _垃圾箱 ),然后使用以下查询查找类似的排序规则:

      SELECT *
      FROM   sys.fn_helpcollations() col
      WHERE  col.[name] LIKE N'{CurrentCollationMinus"_BIN"}[_]CI[_]%';
      

      Japanese_XJIS_100_BIN2 ,请执行以下操作:

      SELECT *
      FROM   sys.fn_helpcollations() col
      WHERE  col.[name] LIKE N'Japanese_XJIS_100[_]CI[_]%';
      

    有关排序规则、编码等的更多信息,请访问: Collations Info

        5
  •  7
  •   David Hermanns    13 年前

    不,只使用 LIKE 这是行不通的。 喜欢 喜欢 只能找到文本“sOmeVal”,而不能找到“sOmeVal”。

    一个切实可行的解决方案是使用 LCASE() 作用 LCASE('sOmeVal') 获取文本的小写字符串:“someval”。如果您对比较的两个方面都使用此函数,它将起作用:

    SELECT * FROM myTable WHERE LCASE(myField) LIKE LCASE('sOmeVal')

        6
  •  4
  •   Federico Colombo Federico Colombo    17 年前

    您可以强制区分大小写,强制转换为varbinary,如下所示:

    SELECT * FROM myTable 
    WHERE convert(varbinary, myField) = convert(varbinary, 'sOmeVal')
    
        7
  •  2
  •   Chase Seibert    17 年前

    你在哪个数据库上?对于MS SQL Server,它是一个数据库范围的设置,或者您可以使用COLLATE关键字在每个查询中使用它。