フロントエンドがAccess2003、バックエンドがWindows NT Server + SQL Server7で稼動しているシステムのバックエンドをWindows 2008 Server(64bit) + SQL Server 2008へ移行する仕事をしている。

基本的には、本社で環境構築&動作確認とAccess2003の小修正を行い、客先へ納品する。本社での作業についてはほぼ終了し、客先へ設置を行い、最終的に現在稼動している旧DBの内容を新DBへインポートをおこなう。

SQL Serverには、インポートプログラムがあるので、ネットワーク上にある旧DBのデータを新DBへ一気にインポートを行うことができる。幸いデータ量もあまり多くはないので、インポート自体は約10分程で終了。あとは、ユーザによる動作確認を行ってもらう段階を残すのみとなった。

が、ユーザの確認を開始した直後に、Accessのエラーメッセージが表示され、クエリが実行できないらしい。調べてみると、旧DBではvarchar(255)のフィールドが、新DBではnvarchar(510)になっていることが原因と判明。最初は、64ビットのインポートツールを使っているから勝手に拡張されたのかと思い、32ビットのインポートツールでやってみても結果は同じ。

念のため、インポート時にエラーが発生しているカラムのサイズを手動で255にするとエラーが出なくなったことから、このデータサイズ変換が原因であることは間違いない……ことまではわかったが、今日は時間切れで終了。

そもそも、nvarcharとは何か調べてみると、

nchar および nvarchar (Transact-SQL)
固定長 (nchar) または可変長 (nvarchar) の Unicode データで、UNICODE UCS-2 文字セットを使用する文字データ型です。

で、数値にはサイズ(バイト数)ではなく、桁数を指定するらしい。と、言うことは文字をUnicodeで格納するために桁数を拡張したため、AccessではJoinできなくなった模様。
回避策としては、新DBの文字コードをCP932にするか、インポート時にカラムのサイズを255にするかしかないのかなぁ…。

問題が発生している箇所は、コードを入れているので、255桁も使用することがないようなので、たぶん問題はないと考えている。
そもそもなんでコードにvarchar(255)なんて指定の仕方をしているんだ?当時の設計者出て来い!!

桁数固定のコードには、char(桁数)を使うのが普通(百歩譲ってvarchar(桁数))と思っている自分は古い人間?

どのへんが「バッサリ」なんだろう?そうか、これは前編だから後編でばっさりするんだなぁ…きっと。