ようやく契約先での作業が増え、このようにネットへのアクセスもできるようになった。が、これから設計と製造のピークを迎える。
客先のSQL Server 2000 から SQL Server 2005 への移行を実施した。
マイクロソフトではデータマイグレーションとして移行支援プログラムを実施していた。今でもあるかは不明・・。
結論から言えば、提供されているマイグレーションツールでは移行がうまくいかなかった。これはマイクロソフトの問題ではなくおそらく私のやり方の問題であろう。
ただ、ツールで問題点は概ね洗い出せた洗い出せたので、あとは自前で環境移行とデータ移行を行った。
ここで詳細の手順を書くのが本意ではないが、簡単に書いておく。
1.ユーザーIDの移行（混合モードを利用しているため）
2.テーブル、ビュー、関数の定義のファイル化
3.ビューや関数の親子関係の調査と処理順番の設定
4.定義を自動作成 (ExcelVBAでツール作成)
5.データを移行 (ExcelVBAでツール作成)
初回は5.で「NULLを空文字に変換して移行」というドジを踏んでしまった。で、5.だけ日を改めた訳であるが、「せっかくだからVB.netで移行ツールを作ろう」ということにした。
DBアクセスも、ADOからADO.netに変えた（VB.netでADOの使い方を知らないだけであるが・・。）
ちなみに、恥ずかしながらADOとADO.netの差異は全く知らずに作成した。（何か違う、ということしか知らない）
テストをしたところ、処理速度は格段に改善された。４０万件くらいのデータ移行が数分の１に短縮した。
さて、これを本番環境で使おうとすると、他のテーブルは問題ないのだが１００万件を超えるテーブルの移行で「タイムアウト発生」で動かなかった。
ADO.netのタイムアウト時間を調整できないか見ても、短時間には分からずじまい。やむなく前回のツールの改良版を利用した。
ADOはタイムアウトにならなかったのにADO.netではタイムアウトになった原因を推測すると、ADOはデータの読み込みが完了してなくてもレコードセットの参照が可能であるが、ADO.netでは読み込みが完了しないと次のアクションに移れない、ということなのではないかと思う。
ADO.netは小中規模のデータベースアクセスには適するが、大量データには向かない、ということが言えるのではないだろうか。
単に私の無知なのかもしれないので、回避方法などがあるのかもしれない。情報をお持ちの方は情報提供をお願いします。
※書き直し ／八月末削除予定 ／DBアクセス