AccessがODBC経由でSQL Serverに接続するようなシステムがあって、今回あるカラムの桁数を変更しなければならなくなった。

経験のある方もおありでしょうが、あるドキュメントの番号として今年の12月に作られるようなものであればDOC201912001のように年号4桁、月2桁、連番3桁のように並べてIDをつけるようなものがありますよね。案件の番号、製品の管理番号、請求書の番号みたいな。

ところが、この連番の部分の桁が4桁になりそうだ、ということになると、このカラムの桁を増やさなければならない。上記の例でいうと、12桁ですから13桁にする必要がある。

テーブルの桁数は大体こんな感じのSQLで変更できる。

ALTER TABLE PRODUCTS ALTER COLUMN PRODUCTID NCHAR(13) NOT NULL;
GO

問題なく桁数は変更できた。そして対応するAccess側のプログラムを13桁になるように作り替える。

これでOKのはず、と思ってAccessのプログラムを起動すると、

[Microsoft][ODBC SQL Server Driver]文字列データの右側が切り捨てられました

というメッセージが消えない。カラムがちゃんと表示されず#Deleteだとか#エラーだとか延々と表示され続ける。

それで、AccessがリンクしているSQL Serverのテーブルを開くと、ちゃんと開けるのです。Accessのフォームが何かを記憶しているのか？SQL Serverのビューにもリンクが張ってある。該当のテーブルのうち、特定の情報だけを表示させるために作ったビューだ。そこでもエラーが出る。

それで、リンクをし直してみたり、ファイルを作り直したりしてみたが、一向に治らない。Viewをリンクさせたものは、そもそも該当の桁が12桁になっていて、テーブル側を直したのにAccess側で13桁にしようとしても、エラーが出てできない。

ODBCが覚えているのか？どこにそんな記憶があるの？

ところが、SQL Server Management Studioで該当のViewを見ると、Viewのカラムの横に(12)という風に桁数が書いてある。

Create Viewを行うときに開発者は桁数を指定したりしない。
SELECT PRODUCTID FROM PRODUCTS;
みたいな文しか書いていないのです。だからViewのPRODUCTIDに桁数があるとは思わなかったのだ。
しかし、実は作成した時点でSQL ServerのViewは桁数を保存しているのです。都度Viewをコンパイルしないで早く動作させるためなのだろうか。

Viewを一度削除してCreateし直してみると、エラーは消えた。

開発者って、大抵時間がつぶれるのは、こういうなんかわからんことなんですよね。