none
異なるデータに対するPRIMARY KEY違反発生について RRS feed

  • 質問

  • いつもお世話になります。

    漢数字を使ったデータをINSERTしようとすると、エラーとなってデータが追加できません。
    エラーの対応方法をご存知の方がおられましたら教えて下さい。

    環境:
      SQL Server 2005 Standard Edition 9.00.3068.00 サーバー照合順序 Japanese_CI_AS
      Windows Server 2003 (Microsoft Windows NT 5.2 (3790))

    照合順序 Japanese_CI_AS のデータベースに対して、下記のスクリプトを実行すると、
    2件目の追加時にエラーが発生します。

    実行したスクリプト
    -------------------------------------------------------------------
    CREATE TABLE [dbo].[TEST](
        [ADDRESS] [nvarchar](50) NOT NULL,
        [CODE] [nvarchar](4) NOT NULL,
    CONSTRAINT [TEST_PK] PRIMARY KEY NONCLUSTERED
    (  [ADDRESS] ASC )
    ) ON [PRIMARY]
    insert [dbo].[TEST] values ('一', '1111')
    insert [dbo].[TEST] values ('一〇', '2222')
    -------------------------------------------------------------------

    エラーメッセージ
    -------------------------------------------------------------------
    (1 行処理されました)
    メッセージ 2627、レベル 14、状態 1、行 8
    制約 'TEST_PK' の PRIMARY KEY 違反。オブジェクト 'dbo.TEST' には重複したキーを挿入できません。
    ステートメントは終了されました。
    -------------------------------------------------------------------

    以上、宜しくお願い致します。

    2008年7月15日 1:30

回答

  • これですね。

     

    漢数字の〇(ゼロ)を含む検索が正しい結果を返さない
    http://support.microsoft.com/kb/912509

    対策ですが、下のようにPRIMARY KEYの列をバイナリ順で定義すればキーが重複することはなくなります。

     

    CREATE TABLE [dbo].[TEST](
        [ADDRESS] [nvarchar](50) COLLATE JAPANESE_BIN NOT NULL,
        [CODE] [nvarchar](4) NOT NULL,
    CONSTRAINT [TEST_PK] PRIMARY KEY NONCLUSTERED
    (  [ADDRESS] ASC )
    ) ON [PRIMARY]

    ただし辞書順ではマッチした条件がバイナリ順ではマッチしなくなる場合があるので注意してください。

    その場合、比較時に明示的にCOLLATEを指定して比較するか(この場合、漢数字の"〇"は比較することができません)

    比較する文字列を条件にマッチするように変換する必要があると思われます。

     

    2008年7月15日 3:12
  • 参考までに、中さんのフィードバックでも解説されていましたので、ご紹介しておきます。

     

    Japanese_CI_ASなどで長音記号(ー)を検索できない
    https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124727

     

    いつ〇などを追加してくれるんでしょうね・・・

    2008年7月15日 3:21

すべての返信

  • これですね。

     

    漢数字の〇(ゼロ)を含む検索が正しい結果を返さない
    http://support.microsoft.com/kb/912509

    対策ですが、下のようにPRIMARY KEYの列をバイナリ順で定義すればキーが重複することはなくなります。

     

    CREATE TABLE [dbo].[TEST](
        [ADDRESS] [nvarchar](50) COLLATE JAPANESE_BIN NOT NULL,
        [CODE] [nvarchar](4) NOT NULL,
    CONSTRAINT [TEST_PK] PRIMARY KEY NONCLUSTERED
    (  [ADDRESS] ASC )
    ) ON [PRIMARY]

    ただし辞書順ではマッチした条件がバイナリ順ではマッチしなくなる場合があるので注意してください。

    その場合、比較時に明示的にCOLLATEを指定して比較するか(この場合、漢数字の"〇"は比較することができません)

    比較する文字列を条件にマッチするように変換する必要があると思われます。

     

    2008年7月15日 3:12
  • 参考までに、中さんのフィードバックでも解説されていましたので、ご紹介しておきます。

     

    Japanese_CI_ASなどで長音記号(ー)を検索できない
    https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124727

     

    いつ〇などを追加してくれるんでしょうね・・・

    2008年7月15日 3:21
  •  CatTail さんからの引用

    これですね。

     

    漢数字の〇(ゼロ)を含む検索が正しい結果を返さない
    http://support.microsoft.com/kb/912509

     

    ありがとうございます。KBではSQL Server 2000 となっていましたが、2005でも発生しているようですね。

     

     CatTail さんからの引用

    対策ですが、下のようにPRIMARY KEYの列をバイナリ順で定義すればキーが重複することはなくなります。

     

    確かに、バイナリ順で定義すればデータは登録できるのですが、この値を使って他テーブルとマッチングさせるのが

    実現したい仕様ですので、根本的な問題解決とはならないのが辛いところです。

    どのように問題解決するかはちょっと考えてみたいと思いますが、適切なヒントを与えてくださいましてありがとうございました。

     

    #漢数字の〇(ゼロ)を入力阻止するしかないのかなぁ・・・。
    2008年7月15日 5:38
  •  trapemiya さんからの引用

    参考までに、中さんのフィードバックでも解説されていましたので、ご紹介しておきます。

     

    Japanese_CI_ASなどで長音記号(ー)を検索できない
    https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124727

     

    上記の紹介、ありがとうございます。

     

     trapemiya さんからの引用

    いつ〇などを追加してくれるんでしょうね・・・

     

    次製品がもうすぐ出る現状では、SQL Server 2005 への対応は難しいのでしょうかね。

     

    #SQL Server 2008 では改善されているのだろうか???

    2008年7月15日 10:26