1

奇妙な問題があります。JDE をアップグレードしており、データベース スキーマが変更されています。一部の char 列が nchar 型に変更されています。ただし、一部の検索が機能しなくなっていることがわかりました。これは、SQL Server 2008 データベース全体で一貫していることがわかりました。

私がテストした DB では、ItemNumber 列は char(25) であり、さまざまな長さのコンテンツがあります。

SELECT * FROM TableName WHERE ItemNumber LIKE '%S'

行の束を返します。ただし、列を nchar(25) に変更すると、そのクエリは ItemNumber 値が「S」で終わり、長さが 25 文字の行のみを返すようになるため、末尾のスペースが (おそらく正しく) 取られているように見えます。考慮する - ワイルドカード値を '%S ' に変更すると、「S」で終わる 24 文字の項目番号が検出されます。

明らかに、これは私たちにとってかなりの問題です。JDE で *S 検索が機能しなくなったためです。これは、基礎となるデータベース呼び出しですべての nchar 列をトリミングする必要があるためです。これは既知の問題ですか、それとも変更が必要な設定ですか?

追加情報 これは ERP システムとそのアップグレードの一部であるため、使用される列の種類を制御することも、生成された基になる SQL を変更することもできません。私たちは Oracle との通話をログに記録しましたが、私の知る限り、彼らはこれを見たことがなく、複製することもできません (ただし、どのような状況でこれを行おうとしているのかはわかりません)。他のデータベース/サーバー全体で発生するため、どこかであいまいな設定ではないのではないかと思います。

4

2 に答える 2

6

LIKE (Transact-SQL)のドキュメントから:

LIKE で Unicode データ (nchar または nvarchar データ型) を使用する場合、末尾の空白は重要です。ただし、非 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)

したがって、考えられる回避策の 1 つは、最初に適切なデータ型を使用することです (また、常に Unicode 文字列のプレフィックスを付けますN'properly'。データ型を正しくできない場合は、RTRIM()Aushin によって投稿された回避策を使用できますが、HLGEM のコメントを念頭に置いてください)。同じように。

于 2013-04-23T14:11:37.803 に答える
3

編集：以下の私の説明は、あなたの質問の誤解に基づいていました。RTRIM は機能しますが、nvarchar ではなく char を使用しているとは知りませんでした。アーロンとゴードンはより良い洞察を提供してくれました。

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

これは、nvarchar(25) の場合、「S」の最後の文字が S であるためです。

nchar(25) の場合、'S' は実際には 'S' + 24 個のスペースです。したがって、最後の文字はスペースです。

于 2013-04-23T13:57:43.947 に答える