Access環境を64bitに変換する方法をお探しですね。

広告

Accessを32bit版から64bit版に移行するときの手順と注意点

Accessを32bit版から64bit版に切り替えるとき、「新しいOfficeを入れ直せば終わり」と思っていませんか? 実は、そう簡単にはいきません。

テーブルとクエリだけのシンプルなAccessファイルなら問題なく開けることもありますが、VBAやWindows API、外部DLL、ODBC接続、古い.mdb形式などが絡んでいると、移行後に突然エラーが出ることがよくあります。

この記事では、Accessを32bit版から64bit版へ移行するための現実的な手順と、事前に確認しておきたい注意点をわかりやすく解説します。

1. 32bit版と64bit版、何が違うの?

Accessの32bit版と64bit版の一番大きな違いは、**使えるメモリの量**と**周辺機能との相性**です。

32bit版Accessは扱えるメモリに限りがあるので、大量のデータを処理するクエリや、複雑なフォーム、重いレポート、VBAでの一括処理などで「メモリ不足です」「システムリソースを超えました」といったエラーが出やすくなります。

一方、64bit版Accessはもっと大きなメモリ空間を使えるので、大規模なデータベースや重い処理に強いです。

ただし、64bit版にすれば必ず安定するわけではありません。

長年使われてきたAccessシステムは、32bit版を前提に作られていることが多く、VBAでWindows APIを呼び出していたり、32bit専用のActiveXコントロールや外部DLLを使っていたりします。

こういった部品は64bit版Accessでそのまま動かないことがあり、移行時のトラブルの原因になります。

まず確認:今使っているAccessは32bit?64bit?

最初に確認すべきなのは、**今使っているAccessが32bit版か64bit版か**という点です。

Windowsが64bit版だからといって、OfficeやAccessも64bit版とは限りません。

企業では互換性を重視して、64bit版Windows上に32bit版Officeを入れているケースが多いんです。

確認方法は簡単です。

Accessを起動して「ファイル」→「アカウント」→「Accessのバージョン情報」を開くと、画面上部に「32ビット」または「64ビット」と表示されます。

移行計画を立てる前に、利用者のPC、開発用PC、実行環境のビット数を必ず確認しておきましょう。

2. 移行前にやっておくべきこと

いきなり本番環境を変更しない!

Access環境を32bit版から64bit版に移行するとき、一番大事なのは**いきなり本番環境を変更しないこと**です。

Accessはファイル単体で動いているように見えても、実際にはリンクテーブル、外部データベース、Excelファイル、CSV、ODBC接続、参照設定、アドイン、プリンター設定など、周辺環境に依存していることがあります。

これらを確認しないまま64bit版へ切り替えると、「フォームは開くのにボタンを押すとエラーになる」「データ取得だけ失敗する」「帳票出力だけ動かない」といった部分的な不具合が発生します。

バックアップと現状の記録

移行前には、Accessファイルの**バックアップを必ず取得**します。

フロントエンドとバックエンドを分けている場合は、フォームやVBAを含むフロントエンドだけでなく、テーブルを格納しているバックエンドファイルも退避しておきます。

また、現在稼働している環境について、次のような情報を記録しておくと、問題が起きたときに原因を切り分けやすくなります。

– 32bit環境のOfficeバージョン
– Access Runtimeの有無
– 参照設定の内容
– ODBCデータソース名
– 接続先サーバー
– 使用している外部DLLやActiveXコントロール

特に確認したいポイント

移行前に確認しておきたい項目をまとめました。

– **Accessファイル形式が.mdbか.accdbか**
– **VBAでDeclareステートメントや外部DLLを使用しているか**
– **ODBC、OLEDB、リンクテーブルで外部データに接続しているか**
– **参照設定に古いライブラリや32bit専用コンポーネントが含まれていないか**
– **複数ユーザーで共有している場合、全員のOfficeビット数が一致しているか**

古い.mdb形式のまま運用している場合は、64bit移行を機に.accdb形式への変換も検討するといいでしょう。

.mdbでも64bit版Accessで開ける場合はありますが、外部接続で古いJet 4.0ドライバーに依存していると問題が出やすくなります。

Access 2007以降の.accdb形式で使われるACEドライバーは、.mdbと.accdbの両方に対応できるので、長期運用を考えるなら新しい形式へ移行するほうが管理しやすくなります。

3. 実際の移行手順

テスト環境で段階的に進める

移行作業は、**テスト環境を用意してから段階的に進めます**。

いきなり本番で試すのは危険です。

まず64bit版Officeまたは64bit版Access Runtimeを導入した検証用PCを準備し、バックアップしたAccessファイルをコピーして開きます。

この時点でテーブルやクエリが開けるか、フォームが表示されるかを確認します。

次にVBAエディタを開き、「デバッグ」→「VBAProjectのコンパイル」を実行します。

コンパイルエラーが出た場合は、その箇所が64bit非対応になっている可能性があります。

Windows API宣言の修正

よく発生するのが、**Windows APIを呼び出すDeclareステートメントのエラー**です。

64bit版Accessでは、API宣言に`PtrSafe`キーワードを追加する必要があります。

たとえば、こんな感じで修正します。

“`vb
‘ 32bit版の書き方
Declare Function GetWindowText Lib “user32” Alias “GetWindowTextA” (…)

‘ 64bit版の書き方
Declare PtrSafe Function GetWindowText Lib “user32” Alias “GetWindowTextA” (…)
“`

ただし、`PtrSafe`を付けるだけで完全に対応できるとは限りません。

ウィンドウハンドル、ポインタ、メモリアドレスなどを扱う`Long`型は、64bit環境では`LongPtr`型へ変更する必要があります。

Long型とLongPtr型の使い分け

ここで注意したいのは、**すべてのLong型をLongPtrに変えるわけではない**という点です。

`LongPtr`はポインタやハンドルなど、環境によってサイズが変わる値を扱うための型です。

通常のカウンタ、件数、フラグ、ミリ秒などの数値は`Long`のままで問題ない場合が多くあります。

むやみに置換すると、逆に型不一致や予期しない動作の原因になります。

API宣言の戻り値や引数が「ハンドルなのか」「単なる整数なのか」を確認しながら修正することが大切です。

32bit版と64bit版の両対応

32bit版と64bit版の両方で同じAccessファイルを使う可能性がある場合は、**条件コンパイル**を使います。

“`vb
#If VBA7 Then

‘ Office 2010以降(32bit/64bit両対応)
#If Win64 Then
‘ 64bit版の宣言
Declare PtrSafe Function GetWindowText Lib “user32” Alias “GetWindowTextA” _
(ByVal hwnd As LongPtr, …) As Long
#Else
‘ 32bit版の宣言
Declare PtrSafe Function GetWindowText Lib “user32” Alias “GetWindowTextA” _
(ByVal hwnd As Long, …) As Long
#End If
#Else

‘ Office 2007以前(32bitのみ)
Declare Function GetWindowText Lib “user32” Alias “GetWindowTextA” _
(ByVal hwnd As Long, …) As Long
#End If

“`

これにより、Office 2010以降の32bit版と64bit版に対応しやすくなります。

ただし、Office 2007以前も対象にする場合は`PtrSafe`が使えないため、さらに分岐を考慮する必要があります。

社内の利用環境が混在している場合は、どのOfficeバージョンまでサポートするのかを先に決めておきましょう。

ODBCドライバーの確認

ODBCやOLEDB接続を使っている場合は、**ドライバーのビット数**も重要です。

64bit版Accessから接続するには、基本的に64bit版のODBCドライバーやOLEDBプロバイダーが必要です。

64bit版Windowsでは、ドライバーの設定場所が2つあります。

– **64bit用のODBCデータソースアドミニストレーター**:`C:\Windows\System32\odbcad32.exe`
– **32bit用のODBCデータソースアドミニストレーター**:`C:\Windows\SysWOW64\odbcad32.exe`

フォルダ名が直感と逆に見えるため、設定時に間違えやすいポイントです。

Accessのビット数に合ったODBC設定を作成し、リンクテーブルや外部アプリからの接続を確認しましょう。

4. 移行後のテストと運用

開けただけでは終わりじゃない

64bit版Accessでファイルが開けたとしても、**移行完了とは考えないほうが安全**です。

実務で使うAccessシステムは、起動、検索、登録、更新、削除、印刷、Excel出力、CSV取込、外部データ連携など、複数の機能が組み合わさっています。

移行後は、利用頻度の高い操作から順にテストし、エラーが出る場所を記録します。

特に、「普段は月末だけ使う処理」「年次更新処理」「管理者だけが使うメニュー」などは見落とされやすいため、業務フローに沿った確認が必要です。

データ量でのテストも忘れずに

テストでは、少量データだけでなく、**本番に近いデータ量でも動作を確認**します。

64bit化によってメモリ制限が緩和されても、Accessファイル自体にはサイズ上限があり、設計が悪いクエリや肥大化した一時テーブルがあれば処理が重くなることがあります。

移行を機に、次のようなメンテナンスも見直すと、単なるビット数変更以上の安定化につながります。

– 最適化と修復
– 不要オブジェクトの削除
– リンクテーブルの再設定
– フロントエンドとバックエンドの分離

32bit版と64bit版は共存できない

また、**同じPCに32bit版Officeと64bit版Officeを共存させることは基本的にできません**。

「Accessだけ64bit、Excelだけ32bit」のような構成も通常は避ける必要があります。

移行期間中に32bit環境を残したい場合は、次のような方法が現実的です。

– 別PCを用意する
– 仮想マシンを使う
– リモートデスクトップ用の環境を準備する

特に業務システムとしてAccessを使っている場合、全員を一斉に64bitへ切り替えるのではなく、「検証担当者→限定ユーザー→全体展開」の順に段階移行するほうが安全です。

今後の運用方針を決めておく

最終的には、**今後の運用方針も決めておく必要があります**。

新規開発や大規模データ処理を前提にするなら、64bit版Accessを標準にするメリットは大きくなります。

一方、古いActiveXや32bit専用DLLに依存したシステムを短期間だけ使い続けるなら、無理に64bit化せず、32bit環境を維持する判断もあります。

重要なのは、現在のファイルが64bitで開けるかどうかだけでなく、**VBA、ドライバー、外部連携、利用者環境、保守体制まで含めて移行計画を立てること**です。

まとめ

Accessを32bit版から64bit版へ移行する際は、次のポイントを押さえておきましょう。

1. **現在の環境を正確に把握する**(ビット数、ファイル形式、VBA、外部接続など)
2. **必ずバックアップを取得し、テスト環境で検証する**
3. **VBAのAPI宣言を修正する**(PtrSafe、LongPtr)
4. **ODBCドライバーのビット数を確認する**
5. **実際の業務フローに沿ってテストする**
6. **段階的に移行し、32bit環境との共存期間を設ける**

事前調査、コード修正、接続確認、段階テストを丁寧に行うことで、移行後のトラブルを大きく減らせます。

焦らず、確実に進めていきましょう。

広告