Microsoft Officeの64bit化

64bitOSはもう一般的で、PC購入時にも特に指定しないかぎりは64bitOSになる。一方、Microsoft Officeの64bit版はまだまだ導入する時期ではないのかと思っていた。指定すれば64bit版Officeが選択できるとは言え、Microsoft自身が32bit版を推奨しているし、敢えて64bit版をインストールするのも気が進まなかった。
また、推奨されている32bit版は64bitOSではWOW64で動作するというのもいただけなかった。

最近、 WindowsXPがインストールできなくて、 VitualBoxを使ってそれなりに使える環境を整えたところだったが、32bit版Accessでは以前からかかえていた問題があった。
月末、請求書を一度に印刷すると、後半罫線だけになってしまい、3回に分けて印刷している。 また、 受注伝票を続けて印刷していると、「メモリを使い果たした！」というエラーメッセージが出て、販売管理システムを再起動し直さなければならなかったりする。
この、問題は以前からかかえていて、あきらめて使っていた。 受注伝票修正するとエラーメッセージが出て、登録されていた受注データが消えていたりする。Setしたオブジェクトはちゃんとnothingしている。どうもDoCmd.OpenReport後、メモリが解放されていないようだ。原因はわかってはいるものの、Accessそのものの問題なので、手の施しようがなかった。この件は64bit版のOfficeを使えば解決するのではないかと考えていた。

Vistaが発売された時、 64bit版が同時発売されていた。 XPも64bitが出ていたので、 Officeも含めて一気に64bit化が進むものと思っていたのだが、Windows7辺りからOSは64bit化したものの、Officeは当面32bit版を推奨という状態だった。

今回、 64bit版のOfficeを調べてみて、 もう導入してもいい時期になったのではないかと思った。
Linux+VirtualBox+WindowsXP+Office2007(32bit)
はそれとして、
Windows10(64bit)+Office2016(64bit)
を試してみることにした。

32bitのaccdbを64bit化しようとすると、 一部コードを書き換えなければならない。
32bit版Officeでも動作するようコンパイル定数VBA7で判断してDeclareするように変更した。
PtrSafeを追加して、引数のポインタはLongからLongPtrに変更した。 また、参照設定しているbioPDFは64bit版をダウンロードしてきた。 その他nmailのdllも64bit版に変更しなければならないのかもしれないが、 現在その部分のコードは使っていないので、 32bit版のままにした。 PostgreSQLのodbcドライバはもちろん64bit版をダウンロードした。

取り敢えずこれだけの変更で64bit版で動作するようになった。 これでメモリ使い果たしのエラーが出るものかどうか確認する。
もし、再度エラーが出るようなら8Gバイトのメモリを16Gに増やしてみようと思う。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
今回、 Windows10+Office365 Soloをインストールしてみたが、 Office365をインストールする時、相変わらずデフォルトでは32bit版になっていた。 やはりまだ、32bit版を推奨している状態は変わっていないのだろうか。実際、コードを修正しなければならないわけだから32bit版を推奨するのは仕方ないのかもしれない。