• ベストアンサー
※ ChatGPTを利用し、要約された質問です(原文:WHERE条件の最終桁のスペースについて質問です。)

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

このQ&Aのポイント
  • あるテーブルのカラム(colA)に「1234」というデータがあるときに、(1)SELECT .... WHERE colA='1234'、(2)SELECT .... WHERE colA='1234 '、(3)SELECT .... WHERE colA='1234 '、(4)SELECT .... WHERE colA='12345'を実行すると、(1)だけOKで、他はNGとなると思い込んでいましたが、実際は、(2)と(3)も同じように検索されてしまいます。WHERE条件の最終桁のスペースは無視されるのでしょうか?
  • SQL-SERVER2005でのWHERE条件の最終桁のスペースについて質問です。テーブルの特定のカラムに対して、スペースが含まれる場合、そのスペースがどのように処理されるか知りたいです。
  • 過去に納品してきたお客様の件数を考えると、WHERE条件の最終桁のスペースの扱いについて不安になりました。SQL-SERVER2005において、スペースが含まれる場合、そのスペースは無視されるのでしょうか?

質問者が選んだベストアンサー

  • ベストアンサー
  • todo36
  • ベストアンサー率58% (728/1234)
回答No.3

> ANSI_PADDING へえー! 知らなかった。 文字列を厳密に比較するときは、 WHERE colA COLLATE JAPANESE_BIN LIKE '1234 ' みたいに書かないといけないのかな?

tadajaa
質問者

お礼

>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 以上

その他の回答 (3)

  • todo36
  • ベストアンサー率58% (728/1234)
回答No.4

> ANSI_PADDING へえー! 知らなかった。 文字列を厳密に比較するときは、 WHERE colA COLLATE JAPANESE_BIN LIKE '1234 ' みたいに書かないといけないのかな?

tadajaa
質問者

お礼

ご回答ありがとうございます。 先ほど質問締め切ろうかなと思いましたが、 具体例までいただきましたので、もう少し実験してみます。 追って、ご連絡いたします。

回答No.2

INF: How SQL Server Compares Strings with Trailing Spaces http://support.microsoft.com/kb/316626 関係ある? #検証はしてない。というかする気がない。

tadajaa
質問者

お礼

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

tadajaa
質問者

補足

その後、いろいろ調べた結果、自己解決しました。 ttp://msdn.microsoft.com/ja-jp/library/ms191529.aspx 『比較では後続の空白は無視されます』と明記してありました。 この際、照合順序やUniCodeなどもう少し勉強します。 解決の糸口やきっかけをいただきましたて、どうもありがとうございました。

  • hanmemomo
  • ベストアンサー率35% (205/580)
回答No.1

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

tadajaa
質問者

お礼

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

関連するQ&A