以前にも書いたネタであるが、解決策が見つかったので記述。本来の解決策では無いが、システム検証には充分使えるでしょう。

 社内開発環境と客先環境でデータベースが違う。データベースソフトウェアはどちらも同じSQL Server 2000なのだけど、唯一違うのが照合順序

 客先はJapanese_BINで構築されており手順書通りのインストールでそれで正解なんだけど、社内は何故かJapanese_CI_ASで構築されています。

 SQL Server 2000のシステムテーブル(SQL Server 2000をインストールすると自動生成されるテーブル)の照合順序は、SQL Serverデフォルトの値。つまりは、客先はJapanese_BIN、社内はJapanese_CI_ASとなるのだ。

 前置きが長くなりましたけど、ある処理を行うと、

equal to 操作での照合順序の競合を解決できません

というエラーメッセージが表示されて先に進む事が出来なかったのだが、これを解決できたのでそのお話。

 システムではエラーログを出力しているので、それを頼りにデバッグ開始。処理を追うと、プログラム側ではなくてストアドプロシージャでの不具合だということが判明した。そのストアドプロシージャ内で作る仮想テーブルが原因のようである。

 各ユーザーテーブルの照合順序は「Japanese_BIN」。ストアドプロシージャで作成される仮想テーブルの照合順序は、SQL Server 2000の規定値、即ち、客先ではJapanese_BIN、社内では「Japanese_CI_AS」。
ユーザーテーブルと仮想テーブルで照合順序が違う。それらを比較したり、何らかの編集をする処理でエラーとなるのですよ。

 根本的な解決は、SQL Server 2000の再構築。つまりは再インストールを行えばよいのですけど、既存のデータベースのバックアップやらが大変なので、どうにかして現状維持で回避できないか考えた。

 以前に、Japanese_CI_AS_Escapeという仮のデータベースを作り(照合順序はJapanese_BIN)、それをSQL Server 2000 のデフォルトデータベースとしたのだけど、根本的な解決策にはならなかったのですね。

 話を戻します。ストアドプロシージャで仮想テーブルを作る処理にとある記述を追加すれば解決する事が判明した。

 各フィールド定義している行に「COLLATE JAPANESE_BIN」と追加するのだ。こうすることで、そこはJapanese_BINであることを明示できたわけで、これでしっかりと文字列比較ができるのだ。
 ただ、このやり方の痛いところは、ストアドプロシージャを直したという事。データベースを丸ごと復旧したり、現地のデータベースをテストとして入れると、当然ながら現地にはCOLLATE JAPANESE_BINの文は入っていないわけで、全てが元に戻ってしまう。なので、そのストアドプロシージャをどこかに対比しておく必要があるのですわ。

今後の作業に、わずれずに追加しておきましょう。