ACCESSの最適化は心臓に悪い

まず２００３ででかいデータベースの最適化をしている最中に、
ESCキーを押して中断すると、
本当はファイルを置き換えていけないのに、
最適化途中のファイルを、本ファイルに置き換えて、
レコードの損失を叩き出します。

ファイルの最適化は、別データベースを別ファイルに作っているため、
ファイルを置き換えない強制終了のほうが安全です。
バグじゃねえのかと思ったんですが、調査しても出てこないんですよねぇ。

さて、今回は２００３形式のDBをACCESS2016で最適化する方法を取っています。
なぜ２０１６なのかというと、Office365のビジネスプレミアムがACCESSも同梱したためです。

で、今回最適化してたら、あるファイルで、主キー+インデックス破壊を起こして、
アプリに悪影響を与えました。
アプリは、二重登録がないように、インデックス指定して、シークコマンドでレコードチェックをしてました。(DAOだとこれが早いかな)
このインデックスが存在していないため、アプリが強制終了してました。
当初、ActiveXオブジェクトが参照できないのか？と思ってたので、
２時間弱悩んでいました。
デバッグメッセージちゃんと作ったほうがいいね。
条件は不明なんですが、
最適化後のテーブルに本来キー違反になるレコードが２個含まれていました。
そのせいで、主キーを解除して、それに紐付いていたインデックスも消された模様です。
いろいろとひどい。

こうならんように、主キーのインデックスはデフォルトのPrimalKeyとしておき、
別にインデックスを振るのが安全パイなのかと思います。
でも、俺デフォルト設定でやっていたはず？と思っているわけです。

そんなわけで最適化はファイルサイズを小さくして読み込みも早くしてくれるんですが、
時々恐ろしいバグが含まれています。
最適化掛ける前に、バックアップを残してからやりましょう。