Access 32bit版から64bit版へ移行すると、これまで動いていたAccessデータベースでVBAのコンパイルエラーや実行時エラーが発生することがあります。
古いAccessパッケージを購入したくても既に販売されていなく、環境構築も難しくなっています。
この記事では、Accessを32bitから64bitへ移行する際に確認したいポイントと、VBAを32bit・64bitの両方で動作させるためのDeclare PtrSafeやLongPtrの修正方法を、実際のコードを使って説明します。
32bitと64bitでの違い
そこで、最近問い合わせが多いのが
「新しく(officeの）バージョンアップしたんだけど動かなくなった。」
Accessのバージョンが32bit→64bitになると動かなくなる可能性があります。
動かなくなる原因と対処方法
理由は色々ありますが、１番大きいのは「Windows APIの宣言」です。
APIを使用している場合は、大概動かなくなります。
対策としては
’32bit
Declare Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
を
’64bit
Declare PtrSafe Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As LongPtr)
にするだけです。64bitの場合「PtrSafe 」が必要となります。
32bitと64bitどちらでも動作させたい場合
しかし、場合によっては両方とりあえず対応にしたい場合もあると思います。
その場合は
' Windows APIの宣言
#If VBA7 And Win64 Then
' 64Bit 版
Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As LongPtr)
#Else
' 32Bit 版
Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#End If
と記述するだけでOKです。コンパイルエラーも起きないので問題ないです。
LongPtrが必要なのは、主にWindows APIでポインターやハンドルなどを扱う場合です。通常の整数値を扱うLong型まで一律にLongPtrへ変更すると、別の問題につながる可能性があります。
その他考えられる要因
それでも、エラーが発生する場合も時々あります。
古いAccessのコードをそのまま移行しようとすると新しいバージョンでは対応していなくて
エラーになるのは良くあることです。
・CALLできない。するとエラーになる。
・変なワーニングメッセージが毎回表示される。
・今まで更新できたのに更新できなくなった。
意外と、10年以上前のコードは特殊な書き方をしているものも時々あって
コードを書き換えると動いたりします。
もし、何か問題がある場合は、修正しますのでお問い合わせをお願いします。
その場合は、Accessのバージョン情報をお知らせ頂けるとスムーズかと思います。
下記のサービスから御依頼頂くことも可能です。
Access業務システムの相談・開発・プログラム修正・保守を行います
コメント