レコードロック

全く訳がわからない。先日から悩んでいるレコードロック。
現象をまとめてみると、

１．WindowsXP+Office2007 32bit環境ではロックがかからない。

２．windows10+Office2016 64bit環境ではでロックする。

３．odbcドライバー経由でロックする。pgAdminでは更新可能な場合もあれば、更新できないこともある。pgAdminで更新できない場合は、日本語文字列の部分が原因になっているようだ。

４．別のサーバーにまっさらの状態でインストールしたPostgreSQLにリストアした場合でも、同じレコードで同じ現象が起こる。
誰もつないでいないサーバーなので、ロックはありえない。また、販売管理プログラム自身で連結フォームにしていたところは、Access内のテーブルに連結するように改めたので、サーバーに重複してリンクしてしまっているということもない。

５．Updateの場合に限る。Insert時にはエラーにならない。


32bit環境からデータ更新した時はエラーにならないので、64bitWindows固有の問題のようだ。いつもとは限らないのだが、pgAdminからも更新できない場合もあるので、必ずしもodbcドライバーの問題とも言えない。
Windows10もUnicodeだし、PostgreSQLもUTF8 にしているので、文字変換エラー、読み間違えとも思えない。実際文字化けは全くない。32bit環境では読み間違えない 文字列を64bit環境では読み違えるケースがあるのだろうか？
読み違えるというか、文字列の一部が予約語と判断しているようなのだが、、、

とりあえずUpdateはあきらめて、一度Deleteしてから改めてInsertするように変更してみようと思う。

----------------------------------------------------------------------
2017/2/28 14:00
recordsetを開いてdeleteしたしてみたが、ロックしてdeleteできなかった。
パススルークエリからdeleteするとOK!
その後、recordset を addnew
なんてこったい、、、

2017/3/1 18:00
パススルークエリならupdate（更新登録）できる！

64bit accdb ほぼ終わりだが、、、

結局のところ何とか使えるかなと思う。
単価登録後、別フォームを開くとAccessが落ちてしまう件が解決したので、後は大きな問題はなくなった。

ただ、プログラムを修理している最中に得意先マスターの１件、単価マスターの１件がodbc経由では更新できなくなった。上記のプログラムを直している最中にロックがかかってしまい、プログラムを更に直さなければならないと勘違いしてしまう始末だった。別の単価を修正してみると、更新できるのにそのレコードだけがロックがかかってしまう。

本当に不思議だ。PostgreSQL側でデッドロックしているのかとも思ったが、pgAdminや、サーバー側でpsqlからはupdateできる。odbcドライバーがそのレコードについて他のユーザーが編集中と判断しているようなのだが、いったいどうゆうことなのかわからない。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
2017/2/27
使っているとロックされてるのは1レコードではないことがわかった。
調べてみるとJetでは2kByteまとめてロックをかけるらしい。該当レコードの周辺2kByteがロックされる。
レコードロックを解除する方法が思いつかいないのだが、PostgreSQLでデーターベースを一度、dropdbしてリストアすれば直るのだろうか。

64bit版accdbで更新するとロックがかかって更新できないレコードも、32bit版accdbならすんなりデータ更新できる。
やはり、64bit版odbcのバグ？

accdb 64bit化、とほほ、、、、

だんだん嫌になってきた。
mdbからaccdbに変換した頃のブログを読み直してみて、結構苦労しているのを思い出した。
その時やったのが、 空のaccdbを用意して、フォームやクエリー、 テーブルをインポートしてきたのだった。
（エクスポート順はテーブル、クエリー、レポート、フォーム。また、リンクテーブルは外部データからリンクを取り直す。）
今日、 それをやってみた、 32bit版のaccdbから64bit版の空のaccdbにエクスポート。
150Mバイトだったファイルサイズが350Mバイトになった。 その後、半日使って、終業時には170Mバイトになった。 何だか不思議な現象だ。 もちろんエクスポートする前に decompileはしていたし、エクスポート後にもdecompileしてみたが、この大きさだった。
それで、 状況が改善されたかというと、全く変わらない。
相変わらず、 単価マスターに新規登録すると、Accessが落ちてしまうし、もっとひどいこともあった。得意先マスターの1レコードがロックがかかって修正できなくなってしまった。
これがまた不思議なのだが、別のPCからもodbc経由だとロックがかかったまま。pgAdminからだと編集できる。odbcドライバーのバグ?

どうも一連の状態を考えてみると、Access2016とodbcドライバーの相性?が悪いのか、odbcドライバーとPostgreSQLの相性が悪いのか、 どうもその辺に原因があるように思う。
結局、 何の対応も思いつかない。
まだまだ、64bit Accessを使うのは時期尚早なのだろうか、、、、、

しかし、odbcを使わないで単独で使うAccess2016には特に問題がなさそうなので、やはりodbcとの取り合い部分にバグが存在しているように思う。 しかし、select分はチャント通っているし、文字バケも無いわけで、特定のテーブルに対してのinsert文やupdate文が通らないか、通っても終了処理が不適切なのか、テーブル構造をからめたodbcドライバーに原因がありそう。 結局、次回PostgreSQLサーバー更新時まで、直りそうもない。やっとられん!!!

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
2017/2/16
単価登録した時、Accessが落ちてしまう件。
連結フォームを開いたまま、新規登録、そのフォームを閉じ、その後、別フォームを開いた時、Accessが落ちてしまう。追加するテーブルの連結をやめて、登録すると落ちなくなった。
連結フォームからコードで連結したテーブルにレコードを追加するのはタブーとは聞いていたが、32bit版では特に止まったりしなかったので、気にしないで使っていた。64bit版では問題になるようだ。

資金繰り

最近、実際に資金繰りをやってます
以前、資金繰りの資料を随分作りましたが、実際にやってみると以前作成した資料は全然使わなかったりします。全く的外れの資料を作っていました。

資金繰りの目的は言ってしまえば支払手形決済を間違いなく行うことで、手形落ちなければ倒産と言うことになってしまうので大変です。
もちろん定期に支払わなければならない当座からの振り込みも大事ですが、もし、数日支払いを延ばしてしまったとしても倒産と言うことにはならないので、重要性は支払手形の次になります。
当座にある程度の余裕資金があればほとんど資金繰りの必要は無いのですが、実際には入出金の確認は最低限必要です。

実際に資金繰りをやってみて全く勘違いしてたと思うのは手形入出金と当座の入出金は別に考えた方がいいと言うことです。当座の収支があるように手形にも収支があります。
手形の収支というのは手形入金と裏書手形払の収支のことで、当座の入出金のように今月入ってくる手形金額と裏書払いに使う手形金額の収支を計算します。
前月繰越手形、当月入金手形、当月裏書手形払、結果として当月手持手形。

また、よく資金繰りのやり方で３ヶ月ぐらい先まで、考えて資金繰り表を作るように言われますが、実際のところ３ヶ月も先の入出金なんてわかりません。ただ前もって分かっている出金はあります。消費税、法人税、賞与、保険支払い。そういったものの出金は考えておかなければなりません。私の場合はそういった大型出金は定期積金にしているのでそれぞれの対応を確認しています。

手形入金と当座が最終的に交わるのは、手持ち手形の取立入金の所だけです。

また実際にやってみるまではよくわからなかったのですが、支払手形が結構見通しがよかったりします。
支払手形決済は完全に予定が把握できます。当座据え置き払いよりよほど、わかりやすかったりします。決済責任は重いですが。