1

我们有一个奇怪的问题。我们正在升级 JDE，并且数据库架构正在发生变化 - 一些 char 列正在更改为 nchar 类型。但是，我们发现某些搜索不再有效，并且我们发现这在我们的 SQL Server 2008 数据库中是一致的：

在我测试的数据库中，ItemNumber 列是一个 char(25) 并且具有不同长度的内容。

SELECT * FROM TableName WHERE ItemNumber LIKE '%S'

返回一堆行。但是，如果我们将列更改为 nchar(25)，则该查询现在只返回那些 ItemNumber 值以“S”结尾且长度为 25 个字符的行，因此现在似乎（可能正确）采用尾随空格考虑到 - 如果您将通配符值更改为“%S”，它会找到以“S”结尾的 24 个字符项目编号。

显然，这对我们来说是一个相当大的问题，因为 *S 搜索在 JDE 中不再起作用，因为底层数据库调用现在需要修剪每个 nchar 列。这是一个已知问题，还是我们需要更改的某个设置？

附加信息 我们无法控制所使用的列类型，也无法更改生成的基础 SQL，因为这是我们的 ERP 系统及其升级的一部分。我们已经记录了与 Oracle 的通话，但据我所知，他们没有看到这一点，也无法复制它（但我们不知道他们在什么情况下尝试这样做），再加上它在我们的其他数据库/服务器上发生的事情让我想知道它是否不是某个晦涩的设置。

4

2 回答 2

6

从LIKE (Transact-SQL)的文档中：

当您将 Unicode 数据（nchar 或 nvarchar 数据类型）与 LIKE 一起使用时，尾随空格很重要；但是，对于非 Unicode 数据，尾随空格并不重要。

我用下表重现了您的问题：

DECLARE @t TABLE(x NCHAR(25));
INSERT @t SELECT N'nanaS';
SELECT x FROM @t WHERE x LIKE N'%S';

结果：

(0 row(s) affected)

但是，如果您NVARCHAR改为使用，则不会出现此问题：

DECLARE @t TABLE(x NVARCHAR(25));
INSERT @t SELECT N'nanaS';
SELECT x FROM @t WHERE x LIKE N'%S';

结果：

x
-----
nanaS

但是，即使NVARCHAR在WHERE子句中转换为，原始表也没有产生预期的结果：

DECLARE @t TABLE(x NCHAR(25));
INSERT @t SELECT N'nanaS';
SELECT x FROM @t WHERE CONVERT(NVARCHAR(25),x) LIKE N'%S';

结果：

(0 row(s) affected)

因此，一个潜在的解决方法是首先使用正确的数据类型（并且始终为 Unicode strings 加上前缀N'properly'。如果您无法使数据类型正确，您可以使用RTRIM()Aushin 发布的解决方法，但请记住 HLGEM 的评论也是。

于 2013-04-23T14:11:37.803 回答
3

编辑：我在下面的解释是基于对您的问题的误读。虽然 RTRIM 可以工作，但我没有意识到您使用的不是 nvarchar 而是 char。Aaron 和 Gordon 提供了更好的见解。

SELECT * FROM TableName WHERE RTRIM(ItemNumber) LIKE N'%S'

这是因为对于 nvarchar(25)，“S”的最后一个字符是 S。

对于 nchar(25)，'S' 实际上是 'S' + 24 个空格。所以你的最后一个字符是一个空格。

于 2013-04-23T13:57:43.947 回答