「レコード/検索条件を開く」ステップとレコードロック

スクリプトステップの一つ、「レコード/検索条件を開く」はどういう時に使うのか？

本スクリプトステップを実行すると現在選択しているレコードをロックできる。FileMaker Ver6以前ではフィールドにカーソルを入れるだけとそのレコードはロックされ、他ユーザは更新不可となったが、7以降では仕様が変わり、フィールド値を変更するか、このステップを実行しない限り、レコードはロックされない。逆にこのステップを実行して301のエラーが返るならば、このレコードは他のユーザが既に編集していることになる。

わかりやすい用例としては、請求書印刷スクリプトの先頭部でこのステップを入れ、他のユーザが当該レコードを編集中している（エラー301が返る）のであればメッセージを表示し印刷を中止する、というのがある。
請求書印刷に限らず、レコードが他ユーザに編集されている状況でなんらかの処理を実行してしまうと不味いという状況は業務アプリではよくあるわけで、本ステップを入れた「g(eneric)競合時処理強制終了」スクリプトを用意しておき、そうした不味い状況が発生しうるすべてのスクリプトの先頭部分に g競合時処理強制終了スクリプト をかましておくことが重要となる。

また、大量のレコードをバッチ更新する場合、FileMakerでは複数行ロックやテーブルロックを行う方法がないので、「レコード/検索条件を開く」ステップを対象レコード間でループ実行させ、301が一度も返らなかった場合にのみ、実際の処理をループさせる（例えば売掛残高更新ループ）というのは一考に値すると思われる。


（土屋）

売上猫くん Standard R5.0 リリースしました！

2013年5月7日、「売上猫くん Standard R5.0」をリリースしました。

売上猫くん Standard R5 のサイト

【お知らせ】
カスタマイズに関する情報をプレリリースサイトに追加しました（2013/3/22）。
iPhone 機能情報をプレリースサイトに追加しました(2013/3/11)。

土屋

突然名前解決できなくなる(次回対策用私的メモ)

今朝、自分のPCを起動して社内の他のPCにアクセスしようとるすと、失敗する。
昨日まで全く問題なかったのに。

  > ping his_pc

とやると、

Ping request could not find host his_pc. Please check the name and try again.

とか返ってくる。以前も同じようなことが数回発生した記憶があるが、解決方法については明確な記憶はなく、記録もとらなかったので、例によって後悔しきり。　よって、今回は本稿に記すことにした。

で、次に

> nslookup his_pc

とやると、


Server:  internal_dns.company.jp
Address:  192.168.0.254

Name:    his_pc
Address:  192.168.0.100


と返ってくる。で、

> ping 192.168.0.100

をやると、正常に応答がある。
よって内部DNSは正しく動作しているようだ。が、前回、内部DNSのレコードが誤って記録されていて、それを修正することにより治ったような記憶が微かにあるので、念のため内部DNSを調べてみる。やはりhis_pc のレコードの内部IPは正しく登録されている。次に第3のPCから

> ping his_pc

をやると正しく応答するので、小生のPCのDNSキャッシュ（DNSリゾルバ・キャッシュ）がおかしいようだ。そこで　

> ipconfig /displaydns

をやってみると、予想に反し、his_pc に関する情報が表示されない。予想では his_pc レコードに誤った値が登録されている筈だったのだが…　本来、ipconfig /displaydns についてちゃんと調べるべきなんだろうが、今日は時間切れ、つか面倒になってきたので、エイヤ！と

> ipconfig /dnsflush

 を実行。　すると、名前解決できるようになった。
1年後、同様の現象が起こったら、その時は /displaydns やDNSリゾルバ・キャッシュをちゃんと調べようと誓うのだった。


（土屋）


参考リンク
TCP/IPの設定を確認する「ipconfig」
WindowsのDNSキャッシュをクリアする方法 ‐ CClener の新バージョンではキャッシュが見れるらしい