accdb 64bit版 結局のところ（まとめ）

レコードロックのエラーが解消できて、一応、32bit版との違いが出尽くしたように思うので一応、まとめ。


移行前の環境（OS、Officeとも32bitは32bit、64bitは64bitに統一）
32bit環境　WindowsXP SP3 ＋　Office2007

移行後の環境
64bit環境　Windows10 ＋　Office2016 (Office365)　

○修正しなければならなかったところ

１．レコードロックのエラー（バグ？）
これが一番、問題だった。
最初はPostgreSQLに直接、連結していて、コードでレコード更新する時にレコードロックしてしまい、これはAccess内に作ったテーブル（１レコードしか含まない）にリンクしてコードで更新する形に変更した。
（この形式だとinsert into TempTable select * from MotoTable where で修正前データを一行で呼び出してこれるので楽）
しかし、これではロックがかかったままだった。
別の空accdbにテーブルをリンクして該当行だけ表示させて、手修正した場合もロックがかかるので、作成したプログラム側の問題ではなかった。
この時はpgAdminでも修正できなかったので、わけが分からなくなった。
別のサーバー、クライアントに同一環境を用意して試してみても、やはりロックがかかるので、何らかバグがありそうだった。
結局、PostgreSQL直接の連結フォームをやめて、パススルークエリで更新ではなく、レコード削除、新規登録することでロックしなくなった。
別のテーブルでも同様の症状が出たが、この時はパススルークエリから更新できた。

2017/4/4
やっぱりこれはハッキリ、バグだ。64bitのWindows10でエラーが出るaccdbファイルを32bit版WindowsXPで実行するとエラーがでない。Access側に原因があるのか、PostgreSQLのodbcドライバー側に原因があるのかはわからない。
リンクテーブルを
rst.Edit
rst.Update
でエラーになってしまう。パススルークエリーでupdateするとOK。

2017/4/6
別のフォームではrst.Editで更新してもエラーにならないこともある。
全くわからない。

2017/4/19
結局、データに特定の文字が含まれている場合は更新できないようだ。
どの文字が含まれている場合かはよくわからない。
rst.Edit
rst.Update
でもだめ、パススルークエリーでもupdateはだめ。
新規登録はできる。
rst.Addnew
rst.Update
はOK。
rst.Deleteはダメ
パススルークエリーからdeleteはOK

まとめると
rst.Delete ×
rst.Edit ×
rst.Addnew OK

パススルークエリー
delete OK
update ×
insert 試してない
(insert into TableMei select * form TempTableMei where cd = ShouhinCD はダメだった）

結局、更新する場合は、パススルークエリーでdeleteして、rst.Addnewする。

2017/4/20
結局これで更新できる。何てことなかった。
Dim lngC As Long
lngC = Me.cd

Me.AllowAdditions = True　　’連結しているテーブルのレコードを進める。
DoCmd.GoToRecord acDataForm, Me.Name, acNewRec
CurrentDb.Execute "delete from t_shouhin where cd = " & lngC　　’ODBC接続しているリンクテーブルを更新
CurrentDb.Execute "insert into t_shouhin select * from temp_shouhin where cd = " & lngC



２．Setfocus（仕様違い？）
フォームでの話。32bit版の時はヘッダーから詳細部へEnterでフォーカスが移動していたが、64bit版だとヘッダーから詳細部へ移動しない。ヘッダー部最後のコントロールからコードで詳細部最初のコントロールへ移動するように修正。

３．F7のショートカットでスペルチェックが起動してしまう（仕様違い？）
Office2007の時はファンクションキーF7にスペルチェックが割り当てられていなかったのか、Office2016だとスペルチェックが起動してしまう。KeyEventを処理する時にkeycode=0を追加してスペルチェックが起動しないようにした。
（Office2007の時はF1でヘルプが起動していた。実際、プログラム作成時には良く使っていたこともあり、これはそのままにして、F1はプログラム側でキー割当しなかった。Office2007ではF7は何もショートカットが設定されていなかったのだと思う。）

４．テーブル表示時にデータソースに標準関数をつかっていると、落ちてしまう（バグ？）
データソースに社名とかで「株式会社」を「(株)」に変換する標準関数を含んでいると、落ちてしまう。
データ数が多い時だけの現象。

５．チェックボックスのNullの画面表示が変わった（仕様違い）
データがNullのチェックボックスはOffice2007だと、Falseの場合とあまり表示が変わらなかったが、Office2016の場合は黒くなってしまい、見た目が非常に悪くなってしまう。ちゃんとFalseをセットしておかなければならない。

６．コントロールの表示が正確になった
テキストコントロールの立体表示がはっきり分かるようになったので、修正することなった。これはバグでもなんでもないのだが、、、

７．OLEオートメーションでの動作不良（バグ？）
AccessからWordを開いて、文書中の表を操作するとうまく動作しない場合があった。
テンプレートとして用意している.doc中の表の行を削除すると列幅が変わってしまった。

８．bioPDFで同期処理ができなくなった
請求書をbioPDFを使ってtif化してＦＡＸ送信していたが、AccessとbioPDFの同期がとれなくなってしまい、複数枚請求書を送信する場合は使えなくなってしまった。実際6枚目くらいからファイル名とデータの整合性がなくなった。Access2016側が速い。
bioPDFを使わないで、Access2016でPDF化することで解消。

９．連結フォームでカレントレコードが先頭行に移動してしまう
フォームでコマンドボタンにファンクションキーを割り当ているが、マウスでクリックする時はフォーカスがコマンドボタンに移動する。ファンクションキーを使った場合は、コードでSetfocusしてやらないと、フォーカスがコマンドボタンに移動しない。これを怠っていて、商品選択画面から伝票入力画面に商品CDをセットする時、カレントレコードが先頭に移動してしまう。伝票入力画面はデータ入力用のテーブルと連結していて、行数に制約を設けていない。
(2017/3/29)

１０．クエリー抽出条件でリストアップされる明細が違う
クエリーで条件「<>1」で表示されてたものが「0 or is NULL」にしないと表示されなくなった。
NULLは「<>1」に含まれなくなった。
(2017/3/29)

１１．「引数が無効です」
リンクテーブルではなく、Access内の「テーブル編集時に、初回のみ "引数が無効です" とエラー メッセージ表示される」。初回だけの場合もあり、毎回表示される場合もある。
Access2007のテーブルをAccess2016の空ファイルにインポートしたせいか。
(2017/4/19)

https://support.microsoft.com/ja-jp/help/2480088


○64bit版にしてよかったところ

１．月末請求書を一度に印刷できるようになった
32bit版では一度に印刷すると、後半、罫線だけ印刷されていたが、64bit版だと一度で印刷できる。
32bit版では3回に分けて、いちいち再起動して印刷していた。

２．「メモリー使い果たした！」エラーが出なくなった
32bit版では続けて受注伝票入力をしていると、「メモリー使い果たした！」エラーが出て、再起動しないと販売管理プログラムが使えなくなったりしていたが、このエラーは出なくなった。
32bit版ではデータ更新時に、一度削除して新規登録する場合もあり、データが消えてしまうこともあって困っていた。

３．AccessでPDF化できるようになった
これはAccess2007でもできていたのかもしれないが、Access2016で初めて使ってみた。bioPDFを使うより簡単だし、速い。

４．動作が速い
PCの性能もあるのだろうが、全般に動作がOffice2007より速いように思う。
商品テーブルは読み順とコード順で一度に２つのフォームを開くようにしていて、タブキーだけでテーブルを移動するようにしている。32bit版の環境ではフォームを移動すると、ソートされていないことがよくあったが、64bit環境ではその回数が激減。1～2秒待てばちゃんとソートされている。


○感想

「○修正しなければならなかったところ」「１」はバグと思うのだが、データベースのフロントエンドで使っている場合、致命的なバグだと思う。32bit版では動作していても64bit版では動作しないので、これが問題になるようだと64bit版への移行は時期尚早ということになる。
ただ、私の場合はデータベースはPostgreSQLなので、PostgreSQL固有の現象かもしれない。例えばSQL Serverなら問題なく動作するのかもしれない。
「OLEオートメションの動作」不良も場合によっては致命的になるかもしれない。
残りの問題は、簡単に対応可能だと思う。

利点については「メモリー使い果たした！」エラーが出なくなったのが大きい。
大量のレポートを発行するのは月に一度だけなので、使い易くはなったが、これだけなら64bit化はあまり意味がない。

まだまだ動作確認中だが、一応、「○修正しなければならなかったところ」「１」は修正方法もわかったので、64bit化は予定通り進めていく予定だ。