WHERE条件の最終桁のスペースについて質問です。

WHERE条件の最終桁のスペースについて質問です。
あるテーブルのカラム(colA)に"1234"というデータがあるときに、
(1)SELECT .... WHERE colA='1234'
(2)SELECT .... WHERE colA='1234 '　　(1234の後に半角スペース)
(3)SELECT .... WHERE colA='1234　' (1234の後に全角スペース)
(4)SELECT .... WHERE colA='12345'
を、実行すると、(1)だけＯＫで、他はＮＧとなると思い込んでいましたが、
実際は、(2)と(3)も同じように検索されてしまいます。

WHERE条件の最終桁のスペースは無視される？
こういうものなのでしょうか？

オンラインヘルプ等からは、それらしい情報が見つけられなかったのですが、もしこの辺の情報がわかるサイト等ご存知でしたら教えてください。

ちなみに、
SQL-SERVER2005(照合順序:Japanese_CI_AS)
colAは、varchar(20)
です。

p.s.
基本中の基本かもしれませんが、いままでずっと勘違いしていたので、過去の納品してきたお客様の件数を考えて恐ろしくなっています。(T.T)

No.3 ベストアンサー 回答者： todo36 回答日時： 2010/07/26 18:14

> ANSI_PADDING

へえー！
知らなかった。

文字列を厳密に比較するときは、

WHERE colA COLLATE JAPANESE_BIN LIKE '1234 '

みたいに書かないといけないのかな？

この回答へのお礼

>himajin100000さん。
ANSI_PADDING設定は影響しない。ですね。英語苦手です。(~_~;)
あと比較演算子(=,<,>)とLike演算子でも、結果が変わってくるのですね...

>todo36さん。
COLLATE(照合順序)まわりは、私も疑っていたのですが、今回の件では解決できなさそうでした。


まだ少ししか調べていませんが、『比較では後続の空白は無視されます』という規格(ANSI/ISO SQL-92)だと解釈しました。
で、最終桁の半角スペースも含めた検索がある場合には注意が必要だという事だと思います。
逆に、この仕様の方が便利な場合も多いと思いますし...

CONVERT(varbinary, column_Name)
などでバイナリ比較が、手っ取り早い解決策のようです。

今回はいろいろと良い勉強になりました。また、この辺のドキュメント類をきっちり確認する重要性を再認識いたしました。
みなさま、ありがとうございました。



以下に、テストした内容を記しておきます。

CREATE TABLE T1 (id int,colA varchar(10))
GO

INSERT INTO T1 VALUES (1,'1234')
INSERT INTO T1 VALUES (2,'1234 ')--最後に半角スペース
INSERT INTO T1 VALUES (3,'1234　')--最後に全角スペース
GO

SELECT * FROM T1 WHERE cola = '1234'
--結果ID(1,2,3)
SELECT * FROM T1 WHERE cola = '1234 '--最後に半角スペース
--結果ID(1,2,3)
SELECT * FROM T1 WHERE cola = '1234　'--最後に全角スペース
--結果ID(1,2,3)
SELECT * FROM T1 WHERE cola = '12345'
--結果ID(なし)
SELECT * FROM T1 WHERE cola like '1234%'
--結果ID(1,2,3)
SELECT * FROM T1 WHERE cola like '1234 %'--最後に半角スペース
--結果ID(2,3)
SELECT * FROM T1 WHERE cola like '1234　%'--最後に全角スペース
--結果ID(2,3)
SELECT * FROM T1 WHERE CONVERT(varbinary, colA) = CONVERT(varbinary,'1234 ')--最後に半角スペース
--結果ID(2)
SELECT * FROM T1 WHERE CONVERT(varbinary, colA) = CONVERT(varbinary,'1234　')--最後に全角スペース
--結果ID(3)
GO

DROP TABLE T1
GO

以上

お礼日時：2010/07/26 20:23

No.4 回答者： todo36 回答日時： 2010/07/26 18:14

> ANSI_PADDING

へえー！
知らなかった。

文字列を厳密に比較するときは、

WHERE colA COLLATE JAPANESE_BIN LIKE '1234 '

みたいに書かないといけないのかな？

この回答へのお礼

ご回答ありがとうございます。

先ほど質問締め切ろうかなと思いましたが、
具体例までいただきましたので、もう少し実験してみます。

追って、ご連絡いたします。

お礼日時：2010/07/26 18:23

No.2 回答者： himajin100000 回答日時： 2010/07/26 17:27

INF: How SQL Server Compares Strings with Trailing Spaces

http://support.microsoft.com/kb/316626

関係ある？

#検証はしてない。というかする気がない。

この回答への補足

その後、いろいろ調べた結果、自己解決しました。

ttp://msdn.microsoft.com/ja-jp/library/ms191529.aspx

『比較では後続の空白は無視されます』と明記してありました。
この際、照合順序やUniCodeなどもう少し勉強します。

解決の糸口やきっかけをいただきましたて、どうもありがとうございました。

補足日時：2010/07/26 18:17

この回答へのお礼

ご回答ありがとうございます。
URLまで教えていただきありがとうございます。

ANSI_PADDINGについての説明のようです。
この辺の設定は、あまり意識してこなかったので(汗)
関係があるのかもしれません。
少し調べてみます。

お礼日時：2010/07/26 18:01

No.1 回答者： hanmemomo 回答日時： 2010/07/26 17:08

そのスペースは「カラム」に属するのであろうがなかろうが無関係ですよ

命令<1つ以上のスペース>オプション<1つ以上のスペース>オプション[以下必要な分のみ」
という書式で、データベースを管理するプログラムそのものは、
スペース区切りに分解してから処理する習性があり、
例としてスペースが間に100個？なんら問題はなかったりします。

この回答へのお礼

ご回答ありがとうございます。
"SELECT"や"GROUP BY"など、各命令やオプションなどは、半角スペース(１個以上)で区切るという事ですね。
今回、それが'1234'や'1234　'(最終桁がスペース)のようにシングルクォーテーションで囲まれた文字列内で起こったので驚いています。

ちなみに、
WHERE colA='　1234'(最初桁がスペース)
では、正しい動き(検索されない)でした。

お礼日時：2010/07/26 17:32