none
SQL Server Management Studioでのクエリの2バイト文字について RRS feed

  • 質問

  • SQL Server 2008環境に対して、SQL Server 2014 Management Studioを使用してデータの管理運用を行っています。

    Select文で
      where [hogehoge] like '%あ%'
    などの2バイト文字をwhere条件として実行した場合
    レコードとしては存在しているにもかかわらず、実行結果として出力がされません。

    設定などの問題と思うのですが対処をご存じの方がいらっしゃったら教えていただけますでしょうか。
    2016年1月27日 4:41

回答

すべての返信

  • N プレフィックスをつけたらどうなりますか?

    【追伸】

    以下は Azure の話ですが、照合順序によっては Azure でなくても以下のような問題が出ます。

    [SQL Azure] Unicode型列(NCHAR/NVARCHAR) に格納されるデータが “?” になる
    http://blogs.msdn.com/b/dsazurejp/archive/2012/06/28/unicode-nchar-nvarchar.aspx

    今さらながらですがご参考まで。

    • 回答としてマーク Tatamumu 2016年1月27日 6:50
    • 編集済み SurferOnWww 2016年1月27日 6:51 追伸追加
    2016年1月27日 4:54
  • 照合順序は何になっていますでしょうか? とりあえず以下のSQLは成功しますでしょうか?

    where [hogehoge] like '%あ%' collate Japanese_CI_AS

    また、検索すると以下の情報もありました。

    SQL Server 2008 および SQL Server 2008 R2 の不具合修正情報の公開 – 照合順序のバージョンが 90 の場合、誤った実行結果が返ってくる事象について
    http://blogs.msdn.com/b/jpsql/archive/2011/12/28/sql-server-2008-sql-server-2008-r2-90.aspx


    ★良い回答には回答済みマークを付けよう! MVP - .NET  http://d.hatena.ne.jp/trapemiya/

    • 回答としてマーク Tatamumu 2016年1月27日 6:50
    2016年1月27日 6:01
  • where [hogehoge] like N'%あ%'

    にて期待した出力結果になりました。

    ありがとうございました。

    2016年1月27日 6:51
  • where [hogehoge] like '%あ%' collate Japanese_CI_AS
    でも同様に期待した出力結果になりました。
    ありがとうございました。



    参考までにSelect対象のテーブルの照合順序についてはJapanese_CI_AS
    サーバデフォルトでの照合順序はSQL_Latin1_General_CP1_CI_AS
    なっていました。

    2016年1月27日 6:54
  • > サーバデフォルトでの照合順序はSQL_Latin1_General_CP1_CI_AS

    Azure SQL DB だったのでしょうか? 以前同じような照合順序の問題の話がありました。

    nvarcharに日本語を入力すると?????????になる
    https://social.msdn.microsoft.com/Forums/security/ja-JP/4de12921-4769-423e-9b39-ba36599fb3f0/nvarchar?forum=sqlazureja

    そのスレッドでも書きましたが、クエリをパラメータ化して ADO.NET + SqlClient 経由で行えば、照合順序が Japanese_CI_AS(デフォルト)でも SQL_Latin1_General_CP1_CI_AS(Azure のデフォルトらしい)でも問題ないと思います。

    実際にアプリからデータを取得する場合はその方向(パラメータ化)で進めることをお勧めします。

    2016年1月27日 7:58