1月12日にOffice2016(64bit)をインストールして、 Office2007(32bit)から移行を始めた。
当初、半年はかかると思っていたが、来週（1月30日）には１台本稼働できそう。
今後、数年かけて移行する最初の１台になりそうだ。
コードの修正もDeclare文はOffice2007と互換性を持たせるためにVBA7定数を使った形に修正した。
それ以外はその場に応じて、バグ対応が必要。
実際、バグについては使いながら直していく他ないのだが、昨日は１度止まっただけで、これなら使えるのではという印象。
バグと思われる主なところはこんなところだ。
１．OLEオートメ-ションがらみのところ
今はOLEオートメーションなんて言わないのかもしれないが、AccessからWord中のテーブルを操作すると動作が変だったりする。Word中のテーブルはExcelになっているらしく、途中で止まるとWordとExcelのプロセスが残っている。
具体的にはWord中のテーブルの行を続けて削除すると列幅が変わってしまい、ページからはみ出してしまう。また、Excelプロセスが残ってしまうので、続けて同一文書を作成するとテーブル操作時、エラーになってしまう。
仕方ないので、行削除しなくても良いように修正した。
２．フォームのタブストップが変
タブストップの動作が少し変だと思う。フォームヘッダーから詳細部に移動しなかったりする。
フォームヘッダーの最後のテキストボックスから強制的に詳細部に移動するようにした。
３．IMEの動作が変
テキストボックスやコンボボックスのプロパティでIMEモードの設定ができるようになっているが、この動作が設定通りにならない。半角数字を入力するコンボボックスで、プロパティではIMEを「オフ」設定しているのに「ひらがな」になってしまう。仕方ないので「フォーカス取得時」にコードでIMEをオフするように修正した。
４．フォームを開くときに落ちてしまうことがある
これは再現性がないので、どういった場合に落ちるのかよくわからない。フォームを閉じて瞬時に別フォームを開くと落ちてしまうことがあったり、メニュー（初期画面）からフォームをクリックした瞬間に落ちてしまう場合もある。これについては対応の仕方が思いつかない。
とりあえず、Hiddenで開いているフォームを閉じる時に、Doeventsを入れてみたのだが、落ちる回数が減ったように思う。
（2017/2/11
単価の新規登録。
フォームの開け閉めが原因で止まってしまうのかと思っていた。実際のところ、Docmd.Closeした後、Doeventsとか入れてみたが、あまり状況は改善されなかった。相変わらず新規登録した直後にコマンドボタンを押しただけでAccessが落ちてしまう。
試しに、単価マスターテーブルのリンクを張り直してみた。
何とこれだけで落ちなくなった。あ～、良かった。
2017/2/13
だめだ、、やっぱり直ってない。）
５．帳票フォームでテキストボックスのコントロールソースに自作した関数を使っていると落ちる
これはレコード件数が多い時。具体的には得意先名を略名で表示させるのに「株式会社」を「(株)」に変換していて、標準モジュールで作成した関数を使ってコントロールソースに設定している。
それも最初は落ちないのだが、続けて開くと閉じる時（？）に落ちる。件数としては500件くらいだと思う。件数が少ないフォームの開け閉めではこんなことはない。
これは、得意先マスターに略名フィールドを追加してコントロールソースに関数を使わないようにして対応した。
後はバグではないのだが、一応、対応しなければならないこととして。
１．フォームの描画が正確になったので、WindowsXPではわからなかったコントロール配置のズレがはっきり分かるようになった。元々作り方が悪かったので、仕方なくコントロールの位置を修正していく。
２．当面、Office2007(32bit版）とOffice2016(64bit版)が共存するので、両方に対応していかなければならない。
64bit版を32bit版に移動すると「参照設定」が変わっているのでエラーになる。Office2016では「Word 16」「Excel 16」を参照しているが、Office2007では「Word 12」「Excel 12」に戻してやらなければならない。
今まで、WindowsXPにこだわっていたが、今回、Windows10をインストールしてみて、ハードの対応が本当に楽で、改めてWindowsのありがたみが分かった。
今、そうでもないのだが、Linuxだとイーサネットドライバーが対応しているかいつも不安だったり、オンボードのグラフィック対応も半ば最初からあきらめていた。
WindowsXPではSATAに対応していないし、USB3.0に対応していない。3Tバイトのハードディスクも基本的に対応していない。メモリーも4Gバイトまで。Windows10についてはそんなことは何一つ心配ない。機器を購入して対応していないということもありえない。まあ、安心この上ない。
ただ、今後、心配なのは以前、Windows7に移行しようとして、しばらく使っていると動作が非常に遅くなり、再びWindowsXPに戻してしまったことがあった。今回もこんなことになるのかもしれず、その点は非常に心配だ。
今回、気が付いたのだが、同様の症状が出ていたWindows7 PCが、いつの間にか速度が普通に戻っていて、しかも新規に購入したWindows10 PCより速かったりする。よく我慢して使っていたものだと思うが、どこかのupdateの時点で直ったのだと思う。
また、Windows10のライセンス認証。128G SSD☓2個でWindows10をインストールしたものの、128Gで十分収まりそうだったので、Dドライブとして認識されているSSDをはずすと、起動しなくなった。あまり画面を詳しく見なかったのだが、「機器構成を見直すか？」といったような画面が表示されて、面倒だったのでSSDをまた元に戻した。
SSD、１個はずしただけで、ライセンスの再認証が必要になるようなら、当然のことながら最初の機器構成はよく考えておかなければならないだろう。
(2017/2/27
128GbyteのSSDカード2枚で構成していたがブートパーティションを間違ってDドライブにインストールしてしまっていた。
ブートに必要なパーティションはWindows10のインストール時には見えるのだが、Windows10を起動してしまうと見えなくなってしまう。なのでインストール後、Dドライブにインストールされているとは気が付かなかった。
使用されていないと思っていたDドライブを外してみて起動できないことで、初めてDドライブにブートハーティションがインストールされてるのがわかった。
SSD 2枚構成にしてしまったためこのようなことになってしまったが、今後は256GbyteSSD 1枚構成にするつもりなのでこのようなことが起こらないものと思う。
ちゃんとブートパーティションをCドライブにインストールした別のPCでは２枚目のSSDを取り外しても何ら問題なかった。)
もう一つ、今回、Windows10(64bit版)をインストールしたのだが、これまで使っていた32bit版のアプリケーションがほぼ全て動作する。どうかするとWindows Vistaにインストールできなかった「筆まめVer.10」まで動作する。すごい！
また、Officeの64bit版に移行することに決めた大きな理由の一つとして、続けて出荷案内書を印刷するとメモリーを使いきってしまい（リソースが解放されず）Accessそのものがエラーを吐いて止まったり、大量の月末請求書を一度に印刷すると、罫線だけの請求書が印刷されたりした。
これはAccessが使用済みのObjectを解放していないか、WindoswXPのメモリー管理がうまくいっていないのではないかと思っていた。64bitOSで32bit版Officeを使う時WOW64で動作するのを疑心暗鬼に思っていたが、特に心配することなく32bit版Officeに移行すればこの問題も解決していたのかもしれない。今となっては確認もできないのだが。
(2017/2/1 月末請求書の一括発行。64bit版だと1回で印刷できた。
また、出荷案内書を連続印刷しても、「メモリーを使いはたした！」という類のエラーは出なくなった。）
Postgresql ODBCドライバー。「psqlodbc 09 05 0400-x64」をインストールした。サーバーのバージョンは9.4。ODBCドライバーもバージョンを揃えて、「09 04」をインストールしようとしたが、Windows10(64bit)にはインストールできなかった。
これまで書いてきたのは販売管理プログラム（ファイルサイズ150Mバイト）だが、ODBCを使っていない給与計算ソフトについては今月、給与計算しただけだが、全く落ちない。Declareしたところもないのでコード修正もなかった。給与明細等の発行はいつも通り行えた。こちらについてはAccess 2016(64bit版）に変更したのも気がつかない。
当初、半年はかかると思っていたが、来週（1月30日）には１台本稼働できそう。
今後、数年かけて移行する最初の１台になりそうだ。
コードの修正もDeclare文はOffice2007と互換性を持たせるためにVBA7定数を使った形に修正した。
それ以外はその場に応じて、バグ対応が必要。
実際、バグについては使いながら直していく他ないのだが、昨日は１度止まっただけで、これなら使えるのではという印象。
バグと思われる主なところはこんなところだ。
１．OLEオートメ-ションがらみのところ
今はOLEオートメーションなんて言わないのかもしれないが、AccessからWord中のテーブルを操作すると動作が変だったりする。Word中のテーブルはExcelになっているらしく、途中で止まるとWordとExcelのプロセスが残っている。
具体的にはWord中のテーブルの行を続けて削除すると列幅が変わってしまい、ページからはみ出してしまう。また、Excelプロセスが残ってしまうので、続けて同一文書を作成するとテーブル操作時、エラーになってしまう。
仕方ないので、行削除しなくても良いように修正した。
２．フォームのタブストップが変
タブストップの動作が少し変だと思う。フォームヘッダーから詳細部に移動しなかったりする。
フォームヘッダーの最後のテキストボックスから強制的に詳細部に移動するようにした。
３．IMEの動作が変
テキストボックスやコンボボックスのプロパティでIMEモードの設定ができるようになっているが、この動作が設定通りにならない。半角数字を入力するコンボボックスで、プロパティではIMEを「オフ」設定しているのに「ひらがな」になってしまう。仕方ないので「フォーカス取得時」にコードでIMEをオフするように修正した。
４．フォームを開くときに落ちてしまうことがある
これは再現性がないので、どういった場合に落ちるのかよくわからない。フォームを閉じて瞬時に別フォームを開くと落ちてしまうことがあったり、メニュー（初期画面）からフォームをクリックした瞬間に落ちてしまう場合もある。これについては対応の仕方が思いつかない。
とりあえず、Hiddenで開いているフォームを閉じる時に、Doeventsを入れてみたのだが、落ちる回数が減ったように思う。
（2017/2/11
単価の新規登録。
フォームの開け閉めが原因で止まってしまうのかと思っていた。実際のところ、Docmd.Closeした後、Doeventsとか入れてみたが、あまり状況は改善されなかった。相変わらず新規登録した直後にコマンドボタンを押しただけでAccessが落ちてしまう。
試しに、単価マスターテーブルのリンクを張り直してみた。
何とこれだけで落ちなくなった。あ～、良かった。
2017/2/13
だめだ、、やっぱり直ってない。）
５．帳票フォームでテキストボックスのコントロールソースに自作した関数を使っていると落ちる
これはレコード件数が多い時。具体的には得意先名を略名で表示させるのに「株式会社」を「(株)」に変換していて、標準モジュールで作成した関数を使ってコントロールソースに設定している。
それも最初は落ちないのだが、続けて開くと閉じる時（？）に落ちる。件数としては500件くらいだと思う。件数が少ないフォームの開け閉めではこんなことはない。
これは、得意先マスターに略名フィールドを追加してコントロールソースに関数を使わないようにして対応した。
後はバグではないのだが、一応、対応しなければならないこととして。
１．フォームの描画が正確になったので、WindowsXPではわからなかったコントロール配置のズレがはっきり分かるようになった。元々作り方が悪かったので、仕方なくコントロールの位置を修正していく。
２．当面、Office2007(32bit版）とOffice2016(64bit版)が共存するので、両方に対応していかなければならない。
64bit版を32bit版に移動すると「参照設定」が変わっているのでエラーになる。Office2016では「Word 16」「Excel 16」を参照しているが、Office2007では「Word 12」「Excel 12」に戻してやらなければならない。
今まで、WindowsXPにこだわっていたが、今回、Windows10をインストールしてみて、ハードの対応が本当に楽で、改めてWindowsのありがたみが分かった。
今、そうでもないのだが、Linuxだとイーサネットドライバーが対応しているかいつも不安だったり、オンボードのグラフィック対応も半ば最初からあきらめていた。
WindowsXPではSATAに対応していないし、USB3.0に対応していない。3Tバイトのハードディスクも基本的に対応していない。メモリーも4Gバイトまで。Windows10についてはそんなことは何一つ心配ない。機器を購入して対応していないということもありえない。まあ、安心この上ない。
ただ、今後、心配なのは以前、Windows7に移行しようとして、しばらく使っていると動作が非常に遅くなり、再びWindowsXPに戻してしまったことがあった。今回もこんなことになるのかもしれず、その点は非常に心配だ。
今回、気が付いたのだが、同様の症状が出ていたWindows7 PCが、いつの間にか速度が普通に戻っていて、しかも新規に購入したWindows10 PCより速かったりする。よく我慢して使っていたものだと思うが、どこかのupdateの時点で直ったのだと思う。
また、Windows10のライセンス認証。128G SSD☓2個でWindows10をインストールしたものの、128Gで十分収まりそうだったので、Dドライブとして認識されているSSDをはずすと、起動しなくなった。あまり画面を詳しく見なかったのだが、「機器構成を見直すか？」といったような画面が表示されて、面倒だったのでSSDをまた元に戻した。
SSD、１個はずしただけで、ライセンスの再認証が必要になるようなら、当然のことながら最初の機器構成はよく考えておかなければならないだろう。
(2017/2/27
128GbyteのSSDカード2枚で構成していたがブートパーティションを間違ってDドライブにインストールしてしまっていた。
ブートに必要なパーティションはWindows10のインストール時には見えるのだが、Windows10を起動してしまうと見えなくなってしまう。なのでインストール後、Dドライブにインストールされているとは気が付かなかった。
使用されていないと思っていたDドライブを外してみて起動できないことで、初めてDドライブにブートハーティションがインストールされてるのがわかった。
SSD 2枚構成にしてしまったためこのようなことになってしまったが、今後は256GbyteSSD 1枚構成にするつもりなのでこのようなことが起こらないものと思う。
ちゃんとブートパーティションをCドライブにインストールした別のPCでは２枚目のSSDを取り外しても何ら問題なかった。)
もう一つ、今回、Windows10(64bit版)をインストールしたのだが、これまで使っていた32bit版のアプリケーションがほぼ全て動作する。どうかするとWindows Vistaにインストールできなかった「筆まめVer.10」まで動作する。すごい！
また、Officeの64bit版に移行することに決めた大きな理由の一つとして、続けて出荷案内書を印刷するとメモリーを使いきってしまい（リソースが解放されず）Accessそのものがエラーを吐いて止まったり、大量の月末請求書を一度に印刷すると、罫線だけの請求書が印刷されたりした。
これはAccessが使用済みのObjectを解放していないか、WindoswXPのメモリー管理がうまくいっていないのではないかと思っていた。64bitOSで32bit版Officeを使う時WOW64で動作するのを疑心暗鬼に思っていたが、特に心配することなく32bit版Officeに移行すればこの問題も解決していたのかもしれない。今となっては確認もできないのだが。
(2017/2/1 月末請求書の一括発行。64bit版だと1回で印刷できた。
また、出荷案内書を連続印刷しても、「メモリーを使いはたした！」という類のエラーは出なくなった。）
Postgresql ODBCドライバー。「psqlodbc 09 05 0400-x64」をインストールした。サーバーのバージョンは9.4。ODBCドライバーもバージョンを揃えて、「09 04」をインストールしようとしたが、Windows10(64bit)にはインストールできなかった。
これまで書いてきたのは販売管理プログラム（ファイルサイズ150Mバイト）だが、ODBCを使っていない給与計算ソフトについては今月、給与計算しただけだが、全く落ちない。Declareしたところもないのでコード修正もなかった。給与明細等の発行はいつも通り行えた。こちらについてはAccess 2016(64bit版）に変更したのも気がつかない。
