久しぶりに、近所ではまっている場面を見かけたので、簡単な事だが書いておこう。

インスタンスの照合順序がJAPANESE_CI_ASの時

クエリ中のパラメタ名が、Abcの時にパラメタ宣言がabcとなっていても、問題なく動作する。

しかし、

インスタンスの照合順序がJAPANESE_BINとか、JAPANESE_CS_AS等、case sensitiveな設定になっている時

クエリ中のパラメタ名が、Abcの時にパラメタ宣言がabcとなっていると、Abcとabcを区別するので、”パラメタが宣言されていない”といった類のエラーになる。

これは、データベースの照合順序がcase insensitiveになっていても、発生する。

パラメタ名はインスタンスの照合順序に依存しているからである。

#ケアレスミス修正

SQLServer2008のバックアップ圧縮はかなり便利だと思うんだけど、まさかEnterpriseEditionのみ対応とは知らなかった。

VIEWの元テーブルの桁数を変更してもVIEWの桁数情報が反映されない。

テストとして以下のクエリを流す。

クエリの内容としては、

１．テーブルtest作成

２．テーブルtestを利用したビューvtestの作成

３．テーブルtestの桁数を伸長

４．テーブルtestにINSERT

５. ビューvtestをselect

create table test (test nvarchar(5))
go
create view vtest as select * from test
go
drop table test
go
create table test (test nvarchar(8))
go
insert into test values('12345678')
go
select * from vtest
go

結果セットとしては、8桁全部持ってくる。

しかし、ManagementStudioで確認した場合VIEWの情報としては、5桁のままである。

つまり、特に、SELECTの結果に影響しないがシステム情報は更新されないままという事。

ちなみに、.NET Framework2.0以降の型付DataSetを作成してみると、MaxLengthはちゃんと8桁になっている。

まぁ、VIEWもちゃんと更新してやれ。という事。

パラメタライズドクエリを使えば’（シングルクォート）についてはエスケープ処理の必要はなくなるけど、Like句の曖昧を求めていない部分の%,_,[の３つについてはエスケープ処理をしなくちゃだめ。