Access管理担当者として悩んでいませんか
- Accessを長年運用している担当者
- Access 32bitから64bitへ移行する担当者
- Copilotで生成したVBAコードが突然エラーになる担当者
- Office更新後にVBAが動かなくなった担当者
本記事では、以下の観点から64bit移行について解説します。
- なぜ突然動かなくなるのか
- どのコードが危険なのか
- 32bitと64bitの違い
- 移行前に確認すべきポイント
- Copilot生成コードの注意点
直面する問題
Accessシステムを長年運用していると、
ある日突然
コンパイルエラー
や
Declare ステートメントは
PtrSafe 属性である必要があります
というエラーが発生することがあります。
原因を調べると、
Windows更新
Office更新
Microsoft 365導入
PC入替
がきっかけになっているケースが少なくありません。
結論から言うと、
32bit時代のVBAコードが64bit Officeに対応していない
ことが原因です。
今回は実務でよく遭遇する64bit対応について整理します。
なぜ突然エラーになるのか
AccessのVBA自体が変わったわけではありません。
問題はOfficeのビット数です。
例えば、
旧PC
Office 2016 32bit
↓
新PC
Microsoft 365 64bit
という環境変更が発生すると、
今まで正常だったAPI宣言がコンパイルエラーになります。
よくあるエラーメッセージ
もっとも有名なのがこれです。
Declare ステートメントは
PtrSafe 属性である必要があります
例
Declare Function GetUserName Lib "advapi32.dll" _
Alias "GetUserNameA" _
(ByVal lpBuffer As String, _
nSize As Long) As Long32bit環境では問題ありません。
しかし64bit環境ではエラーになります。
修正方法
64bit対応版です。
Declare PtrSafe Function GetUserName _
Lib "advapi32.dll" _
Alias "GetUserNameA" _
(ByVal lpBuffer As String, _
nSize As Long) As Longまずは
PtrSafeを追加します。
これが第一歩です。
PtrSafeだけでは直らない場合
実はここが重要です。
初心者向け記事では
PtrSafeを付ければOK
と書かれています。
しかし実務では不十分です。
例えばポインタを扱うAPIでは
Longを
LongPtrへ変更する必要があります。
例
#If VBA7 Then
Declare PtrSafe Function FindWindow _
Lib "user32" Alias "FindWindowA" _
(ByVal lpClassName As String, _
ByVal lpWindowName As String) _
As LongPtr
#Else
Declare Function FindWindow _
Lib "user32" Alias "FindWindowA" _
(ByVal lpClassName As String, _
ByVal lpWindowName As String) _
As Long
#End Ifこれが実務でよく使われる書き方です。
特に注意が必要なAPI
以下を利用している場合は要確認です。
FindWindow
GetWindowLong
SetWindowLong
ShellExecute
GetUserName
Sleep
CopyMemory
特に古いAccessシステムでは
画面制御
Excel操作
ファイル操作
で利用されていることがあります。
移行プロジェクトでよく起きる失敗
失敗① コンパイル確認をしていない
Accessは実行されるまでエラーが出ないコードがあります。
特に
数年前から実行していない機能
が危険です。
移行時は必ず
デバッグ
↓
VBAプロジェクトのコンパイル
を実施しましょう。
失敗② 開発環境だけで確認
開発PCで動いても安心できません。
利用者PCで
32bit
64bit
権限
が異なる場合があります。
本番環境での確認が必須です。
失敗③ Access Runtimeを考慮していない
配布先がRuntime利用の場合、
想定外の動作になるケースがあります。
特に社内展開しているシステムでは注意が必要です。
Copilotでコード変換できるのか
最近増えているのが、
既存VBAをCopilotへ貼り付けて修正する方法です。
例えば、
このVBAを
64bit対応へ修正してください。
PtrSafe
LongPtr
条件コンパイルも含めて
修正してください。
という依頼です。
かなり効率化できます。
ただし注意点があります。
Copilot生成コードの落とし穴
Copilotは高確率で
PtrSafe
を追加してくれます。
しかし、
Long
LongPtr
の判定までは誤ることがあります。
その結果、
コンパイル成功
↓
実行時異常
になる場合があります。
生成結果をそのまま採用せず、
API仕様を確認しましょう。
実務でおすすめの移行手順
Step1
まずAPI宣言を検索
Declare
で検索します。
Step2
64bit非対応箇所を抽出
PtrSafeなし
LongPtrなし
を確認します。
Step3
全機能コンパイル
デバッグ
↓
VBAプロジェクトのコンパイル
を実施します。
Step4
実際の業務シナリオを確認
以下を実行します。
CSV取込
Excel出力
PDF出力
メール送信
集計処理
既存機能を一通り試験します。
独自チェックリスト
移行前に確認したい項目です。
□ Office 64bitへ変更予定
□ Declare文が存在する
□ Windows APIを使用している
□ Access 2010以前から利用している
□ 開発者が退職済み
□ ドキュメントが残っていない
□ 「触ると壊れる」と言われている
3つ以上該当する場合は、
64bit対応の事前調査をおすすめします。
まとめ
Accessシステムの64bit対応では、
PtrSafe追加
だけで終わらないケースが多くあります。
重要なのは
- API宣言の確認
- LongPtrの見直し
- 条件コンパイル利用
- 本番環境での検証
です。
特に5年以上運用しているAccessシステムは、
将来的なPC更新やMicrosoft 365導入に備えて、
一度コンパイルチェックを実施しておくことをおすすめします。
コメント