もう5年以上前にパラメタライズドクエリのパラメタ名でトラブった話

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

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

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

しかし、

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

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

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

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

#ケアレスミス修正

FacebookTwitterHatenaTumblr共有

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

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

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

クエリの内容としては、

1.テーブルtest作成

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

3.テーブルtestの桁数を伸長

4.テーブルtestにINSERT

5. ビュー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もちゃんと更新してやれ。という事。