結局のところ何とか使えるかなと思う。
単価登録後、別フォームを開くとAccessが落ちてしまう件が解決したので、後は大きな問題はなくなった。
ただ、プログラムを修理している最中に得意先マスターの1件、単価マスターの1件がodbc経由では更新できなくなった。上記のプログラムを直している最中にロックがかかってしまい、プログラムを更に直さなければならないと勘違いしてしまう始末だった。別の単価を修正してみると、更新できるのにそのレコードだけがロックがかかってしまう。
本当に不思議だ。PostgreSQL側でデッドロックしているのかとも思ったが、pgAdminや、サーバー側でpsqlからはupdateできる。odbcドライバーがそのレコードについて他のユーザーが編集中と判断しているようなのだが、いったいどうゆうことなのかわからない。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
2017/2/27
使っているとロックされてるのは1レコードではないことがわかった。
調べてみるとJetでは2kByteまとめてロックをかけるらしい。該当レコードの周辺2kByteがロックされる。
レコードロックを解除する方法が思いつかいないのだが、PostgreSQLでデーターベースを一度、dropdbしてリストアすれば直るのだろうか。
64bit版accdbで更新するとロックがかかって更新できないレコードも、32bit版accdbならすんなりデータ更新できる。
やはり、64bit版odbcのバグ?
単価登録後、別フォームを開くとAccessが落ちてしまう件が解決したので、後は大きな問題はなくなった。
ただ、プログラムを修理している最中に得意先マスターの1件、単価マスターの1件がodbc経由では更新できなくなった。上記のプログラムを直している最中にロックがかかってしまい、プログラムを更に直さなければならないと勘違いしてしまう始末だった。別の単価を修正してみると、更新できるのにそのレコードだけがロックがかかってしまう。
本当に不思議だ。PostgreSQL側でデッドロックしているのかとも思ったが、pgAdminや、サーバー側でpsqlからはupdateできる。odbcドライバーがそのレコードについて他のユーザーが編集中と判断しているようなのだが、いったいどうゆうことなのかわからない。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
2017/2/27
使っているとロックされてるのは1レコードではないことがわかった。
調べてみるとJetでは2kByteまとめてロックをかけるらしい。該当レコードの周辺2kByteがロックされる。
レコードロックを解除する方法が思いつかいないのだが、PostgreSQLでデーターベースを一度、dropdbしてリストアすれば直るのだろうか。
64bit版accdbで更新するとロックがかかって更新できないレコードも、32bit版accdbならすんなりデータ更新できる。
やはり、64bit版odbcのバグ?