結論：古いmdbは「開く」「動かす」「移す」で別々に詰まる
.mdbや.accdbというファイルそのものに、32bit・64bitの区別はありません。bit数が効いてくるのは、そのファイルが外から呼び出している型ライブラリ、ActiveXコントロール、ODBCドライバーのほうです。10年20年前のmdbを今のPCへ持っていったとき、この呼び出し先が見つからなければ、そこで止まります。
つまずく場所は、大きく3つに分かれます。ファイルを開く段階、開いたあとVBAを動かす段階、データを別のデータベースへ移す段階です。原因も対処も違うので、この順に見ていきます。作業に入る前に原本のコピーを取り、以降はコピーだけを触ってください。
開く段階：まず、手元のファイルがどの形式かを確かめる
Microsoftが「開いて普通に使える」と明記している.mdbは、Access 2000形式とAccess 2002-2003形式の2つです。原文は「If the file is stored in the Access 2002-2003 or Access 2000 file format, you can open it and use it normally」で、Access 97形式はこの並びに入っていません（Microsoft Support: Which Access file format should I use?）。
見分け方：拡張子が.mdbのファイルなら、コピーを現行のAccessで開いてみます。問題なく開けるなら、形式を理由にした手当ては要りません。開けないなら、破損を疑う前に97形式以前の可能性を先に考えてください。破損とそれ以外の切り分けはAccessが開かない・起動しないときのチェック手順にあります。
Access 97形式は、直接.accdbに変換できない
Access 2013以降では、Access 97のmdbを直接.accdbへ変換できません。案内されている道は、いったんAccess 2003でAccess 2002-2003形式へ変換してから現行のAccessで保存し直す、という中間手順です（Microsoft Support: Convert a database to the .accdb file format）。Access 2007またはAccess 2010が動くPCが残っていれば、そちらで開くと「データベース拡張ウィザード」が起動し、一度の操作で.accdbになります。フォームやレポートまで含めて丸ごと移すなら、この世代のAccessが動く環境を用意するのが確実です。
Access 2.0・95を開けるのは、Access 2007まで
もっと古い世代はさらに限られます。Access 2.0とAccess 95について、Microsoftは「Access 2007 was the last version to support opening, importing, linking or exporting to Access 2.0 and Access 95（開く・インポート・リンク・エクスポートに対応した最後のバージョンがAccess 2007）」と明記しています。同じページが載せている手順も、テーブル・クエリ・マクロのインポートを含めてすべてAccess 2007での操作です（Microsoft Support: Import Access 2.0 and Access 95 databases into current versions）。VBAコードを含むフォーム・レポートやモジュールについては、Access 2000〜2003で先に変換する手順が別に案内されています。
手元が.mdeや.accdeのときは、先に元ファイルを探す
.mdeや.accdeは、VBAの編集可能なソースコードを取り除いた状態で保存されたファイルです。作成時には元のファイルが別途残る作りになっています（Microsoft Support: Hide VBA code from users）。裏を返せば、その元ファイルが失われていると、コードを読み直しての修正はできません。さらにこのファイルはコンパイル済みのため、32bit版で作られたものを64bit版Officeで動かすには、64bit向けの再コンパイルが要ります（Microsoft Support: Choose between the 64-bit or 32-bit version of Office）。再コンパイルには元ファイルが要るので、探す順番としてはここが先です。対処はaccde/mdeで中身が見られないAccess｜解析して移行する方法にまとめました。
動かす段階：参照設定と、32bit前提の部品
ファイルが開けても、VBAが素直に動くとは限りません。古いmdbは、その時代のPCに入っていた型ライブラリやActiveXコントロールを名指しで参照しているからです。
参照設定の「MISSING」は、無関係なコードまで巻き込む
参照先が移行先のPCに無ければ、参照設定に「MISSING: 〜」と表示され、モジュールのコンパイル時やプロシージャの実行時にエラーになります（Microsoft Learn: Database contains a missing or broken reference（KB283806））。症状はその部品まわりに収まりません。Microsoftが公開している再現手順でも、フォームにActiveXコントロールを1つ置いてそのocxをリネームしただけで、まったく別のモジュールのコンパイルが通らなくなる例が示されています。
直し方：Alt+F11でVisual Basic Editorを開き、［ツール］→［参照設定］に「MISSING:」の行が無いかを最初に見てください。参照先ファイルを本来のパスに戻すか、新しい場所のファイルへ参照を張り直すのが本筋です。チェックを外して消す方法も案内されていますが、そのライブラリを使っているコードが残っていれば実行時に落ちるため、使っていないと確認できた場合に限ります。旧バージョンから変換したデータベースについては、古い世代のDAOへの参照は外してよい旨もMicrosoftの資料にあります（Microsoft Learn: How to resolve Access reference issues（KB310803））。参照を直したら、必ず［デバッグ］→［コンパイル］まで通します。
64bit版Officeでは、元のパスに戻しても直らない部品がある
VB6世代の32bit専用ActiveXコントロールは、64bitプロセスに読み込めません（Microsoft Learn: Compatibility issues in Office）。前項の「元のパスにocxを戻す」がここでは効かない、ということです。Declare文のほうも、PtrSafeを付けたうえで、ポインターやハンドルを保持する引数・戻り値の型をLongPtrに直す必要があります（Microsoft Learn: 64-bit Visual Basic for Applications overview）。直すのはポインターとハンドルだけで、通常の32bit整数はLongのままです。点検の手順とコード例はAccess 32bit版から64bit版への移行で壊れるものに分けて置いています。
手元のOfficeが何bitかは、Accessで［ファイル］→［アカウント］→［Accessのバージョン情報］を開くと、バージョン番号と並んで表示されます（Microsoft Support: What version of Office am I using?）。
ODBCのDSNは、32bitと64bitで管理ツールが別
64bit Windowsには、ODBCデータソース管理ツールが2つ入っています。32bitドライバーのDSNは C:\Windows\SysWOW64\odbcad32.exe、64bitドライバーのDSNは C:\Windows\System32\odbcad32.exe で管理します。
64bit側のツールで32bitドライバーのDSNを設定・削除しようとすると、「The specified DSN contains an architecture mismatch between the Driver and Application」というエラーになります。公式ドキュメントがその例に挙げているのが、Accessのmdbドライバーです（原文の表記は Driver do Microsoft Access (*.mdb)。Microsoft Learn: Managing Data Sources）。このエラーが出たら、開いている管理ツールのbit数を疑ってください。
ACEの32bit版と64bit版は、素直には同居しない
Access本体を入れずに.mdbを読む用途では、Access Database Engine（ACE）を使います。JETのOLE DBプロバイダーとODBCドライバーは32bit版しか提供されておらず、64bitのアプリケーションから.mdbにつなぐ経路はACE側になる、とMicrosoftが説明しています（Microsoft Learn: Jet ODBC driver is available in 32-bit version only）。ここでもbit数が問題になります。共存させる手順として、ドライバーの全アンインストール、レジストリの mso.dll キーの削除、コマンドラインからの順序を決めた再インストール、という流れが案内されています（Microsoft Learn: Cannot establish connection to Access Database Engine OLE DB）。ただしこれはAccess Database Engine 2016 Redistributableについての案内です。
そのAccess Database Engine 2016 Redistributableは、延長サポートが2025年10月14日に終了しています（Microsoft Lifecycle: Access Database Engine 2016 Redistributable）。レジストリを触ってサポート切れのコンポーネントを同居させる形になるため、当社としては、共存はさせず、読み取り用のPCを1台、bit数を揃えて用意し、そこで期間を区切って使うほうを基本方針としています。無償で配布できるAccess Runtimeを使う道はAccess Runtimeで無償配布する延命策で扱っています。
移す段階：消える機能と、型・文字コード
ここからはデータの引っ越しです。形式を.accdbに変えるだけでも失われるものがあり、SQL Serverなど外のデータベースへ出すなら型の対応も決めることになります。
accdbに変換すると戻せなくなる機能
次の2つはaccdb形式には存在しません。変換ではなく作り直しになります。
| 機能 | accdbでの扱い | 作り直しの方向 |
|---|---|---|
| ユーザーレベルセキュリティ（.mdw） | 非対応 | 移行先DBのログインとロール、またはアプリ側の権限管理へ移す |
| データベースレプリケーション | 非対応 | バックエンドを1か所に集約し、同期を前提としない設計へ |
ユーザーレベルセキュリティについてMicrosoftは「Do not convert your database to one of the new file formats if you want to continue using user-level security（使い続けたいなら新しいファイル形式へ変換しないこと）」と明記しています（Microsoft Support: What happened to user-level security?）。同じページには、ウィザードで既定のワークグループ情報ファイルを指定している場合、Access起動時に /WRKGP スイッチでその.mdwを指す必要があるとも書かれています。旧環境から.mdbだけを持ってきて.mdwを置いてくると、この指定ができません。
レプリケーションのほうも、.accdbでは使えず、使っている場合はレプリケーション抜きで作り直すことになります（Which Access file format should I use?）。拠点ごとにファイルを配って同期していた運用は、設計のやり直しです。形式そのものの差は.accdbと.mdbの違い｜Accessのファイル形式と変換手順で一覧にしています。
SQL Serverへの型対応で、手を入れておきたい行
MicrosoftのSSMA（SQL Server Migration Assistant for Access）が既定で使う型対応から、注意の要る行を抜き出します（Microsoft Learn: Project Settings (Type Mapping)）。
| Access側 | SQL Server側（既定） | 見落としやすい点 |
|---|---|---|
| decimal | float | 既定のままだと浮動小数点になる |
| integer（整数型） | smallint | Accessの整数型は2バイト（-32,768〜32,767） |
| text[n] | nvarchar(n)／Access 97はvarchar(n) | 97世代だけ非Unicode扱い |
| memo（メモ型） | nvarchar(max)／Access 97はvarchar(max) | 同上 |
| longbinary（OLEオブジェクト型） | varbinary(max) | ビットマップ化されて入っていることがある |
小数を扱う列がdecimalのままfloatへ流れるのは、あとから気づくと直しにくい箇所です。当社では、decimal型の列は既定任せにせず、移行先の型を個別に指定することをおすすめしています。表に挙げた整数型の範囲はMicrosoft Support: Introduction to data types and field propertiesにあります。
Access 97のテキストだけ、非Unicodeとして扱われる
型対応の表では、テキストとメモの行だけ97世代が分かれています。SSMAの既定では、Access 97のテキストは varchar、それ以降の形式は nvarchar です。varchar はUnicodeを前提としない型なので、97世代のファイルを移すときは、移した先で実データを開いて文字を確認してください。件数の照合だけでは、文字化けは検査をすり抜けます。
OLEオブジェクト型は、取り出せる保証がない
この型が対応しているのはWindowsビットマップ（.bmp）とDIB（.dib）だけで、JPEGなど他の形式を入れるとデータシート上は「Package」と表示されます（Microsoft Support: What to do when you see "Package" instead of "Bitmap Image"）。かつてのOLEは画像や文書のビットマップ版を作って格納する作りで、Microsoft自身が「元のファイルの10倍もの大きさになることがある」と書いています（Microsoft Support: Attach files and graphics to the records in your database）。テーブルに画像が入っているように見えても、列から取り出したバイナリが元のJPEGそのものとは限りません。移行先で復元できるかどうかは、見積もりの前に1件開いて確かめておきます。
リンクテーブルは、置き場所を変えただけで切れる
テーブルを外部に出したあともAccessをフロントエンドとして残す場合は、リンクを張り直します。［外部データ］→［リンクテーブルマネージャー］でデータソースを選び、リンク先を編集してください（Microsoft Support: Manage linked tables）。バックエンドの置き場所を変えるだけでもリンクは切れるので、共有フォルダのパスが変わる移設では最初に点検する箇所です。データだけ先に外へ出す進め方はデータだけ先に移すAccess部分移行で扱っています。
まずやること
移行先を決める前でも進められるのが、次の5つです。
- 原本のコピーを作り、以降の作業はコピーに対して行う
- 拡張子が.mdbなら、コピーを現行のAccessで開く。開けなければ97形式以前か破損を疑う
- 手元のファイルが.mdeや.accdeでないか、元の.mdb／.accdbが残っているかを確認する
- .mdw・バックエンドmdb・ocxなど、付随ファイルが揃っているかを確認する
- OLEオブジェクト型の列と、ユーザーレベルセキュリティ・レプリケーションの使用有無を確認する
移行先の環境が決まってからが、次の3つです。
- ［ファイル］→［アカウント］→［Accessのバージョン情報］で移行先Officeのbit数を確認する
- 参照設定に「MISSING:」が無いかを見て、［デバッグ］→［コンパイル］を通す
- リンクテーブルがあれば、リンクテーブルマネージャーでリンク先を張り直す
お持ちのAccessを当社で解析できる状態かどうかは、無料の解析可否チェックの設問に答える形で確認できます（約2分・ファイル送信不要）。
よくある質問
Access 2003や2010が動くPCが社内にもうありません。97形式のmdbは諦めるしかないですか？
データが読めないと決まったわけではなく、変換の道が塞がっているだけです。まずは社内の棚卸しで、旧バージョンのAccessが残った端末が無いかを探すところからです（社内のAccessファイルを棚卸しする方法）。見つからなければ、旧環境を仮想マシンなどで用意して変換する道になります。旧環境を立てるなら、OSとOfficeのライセンス条件の確認も要ります。
PCを入れ替えて64bit版Officeになりました。mdbは開けますか？
Access 2000形式・Access 2002-2003形式であれば、形式を理由に開けなくなることはありません。詰まるのは本文で挙げたDeclare文とActiveXコントロール、そしてODBCのbit数のほうです。
移した先と原本、どこまで一致を確認すれば移行が済んだと言えますか？
件数だけでは足りません。金額の合計、日付の最小と最大、コード値の種類数まで一致を確認できて、はじめて済んだと言えます。その確認が終わるまでは原本を保管しておいてください。原本が破損していた場合の扱いは「データベースの形式を認識できません」エラーの原因と復旧手順を参照してください。
変換の前に最適化しておくべきですか？
当社では、コピーに対して最適化／修復をかけてから作業に入ることをおすすめしています。ただし最適化で直る壊れ方には限りがあります。範囲はAccessの「最適化/修復」の正しい使い方にまとめました。