みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)
You are not logged in.
Pages: 1
お世話になります。
ポータルを使用した排他制御というものを行いたいのですがうまくいかずに困っています。
過去の質問(https://fm-aid.com/bbs2/viewtopic.php?id=1147)を参考に以下のように試してみましたがロックが掛かりません。
おそらくやり方が間違っているのだと思うのですがもう少しだけ砕いた手順で教えていただけないでしょうか?
【テーブル構成】
排他・親・子の3つ
【リレーション】
排他テーブルと親でマルチキーテキストでリレーション
排他テーブルと子でマルチキーテキストでリレーション
【レイアウト】
排他テーブルに親と子のポータルを置く
【質問】
1、排他レイアウト上の排他テーブルのマルチキーテキストフィールドにロックしたい親のIDを入力したあとどのようにすれば排他がかかるのでしょうか?
2、ほかの人がレコードロックしていた時のエラーを取得するのはどのようにすればよろしいでしょうか?
至らない頭で申し訳ございません。
自分なりにいろいろ調べてみましたがよくわかりませんでした。
他にも参考にしたサイトです。
https://www.geistinteractive.com/2019/0 … s-portals/
>#1 そんな面倒な事でなく、
(※確認テストはしていませんが、関連参考から確か、)
排他ロックしたいレコードをポータルに表示させ、
そのポータルを表示している親レコードをロック(=レコードを開く)すれば、
ポータル内の関連レコードもすべて同時一括で自動ロックできる、
そんな簡便な仕様だったかと!
●関連参考「FileMakerのトランザクション」→ https://notonlyfilemaker.com/2019/04/fi … nsactions/
Offline
親レコードを開いてもロックされないんです。
これってほかのユーザーも排他テーブルのレイアウト上で作業していることが前提なんでしょうか?
簡単なもので構いませんのでデモファイルとかってありませんでしょうか?
本当に少額ですがお礼をさせていただきたいと思っております。
>#1 そんな面倒な事でなく、
(※確認テストはしていませんが、関連参考から確か、)排他ロックしたいレコードをポータルに表示させ、
そのポータルを表示している親レコードをロック(=レコードを開く)すれば、
ポータル内の関連レコードもすべて同時一括で自動ロックできる、
そんな簡便な仕様だったかと!●関連参考「FileMakerのトランザクション」→ https://notonlyfilemaker.com/2019/04/fi … nsactions/
現在、共有環境でなく、このために新規セットアップも面倒なので、
申し訳ないですが、動作確認テストができません。
共有環境ある方で、どなたかボランタリで動作検証ねがえませんか?
Offline
レコードを開くだけでは、排他はかかりません。レイアウト上のいずれかのフィールドに入ってみると、他のユーザーへは排他がかかるはずです。
Offline
最近のバージョンでロックするには、フィールドに入るのではなく、スクリプトで「レコードを開く」か、どこでもフィールド内容を変更する必要があるはずです。
・親レコードを開く・親レコードを編集状態にする(フィールドに入力して確定しない)
・子レコードのフィールドにカーソルを入れる
だけでは子レコードはロックされません。
子レコードをロックするためには
[レコード/検索条件を開く]
をポータルの各行で実行する必要があります。
テストは簡単ですから手元で試されれば良いでしょう。
新規ウインドウを開き子レコードのテーブルを表示すればOKです。
元のウインドウで操作をして子レコード側のウインドウで編集ができたらロック失敗です。
とりあえずサンプル
http://bit.ly/2JirP5A
Last edited by Moz (2019-05-14 09:42:08)
Offline
確かに、仕様が変わっていますね。関連レコードへ移動(新ウィンドウ) して、フィールドに入って、ロックがかかりますね。終了すればウィンドウを閉じるだけですけど、昔より面倒です。
Offline
『最近は個別に開かなければイケなくなった!』
と云うことは、
『本来目的の一括ロックする方法はナイ!!』
なら、あえてポータルを介する意味も無いですね。
Offline
手動操作ではポータル行のフィールドに入った状態でその関連レコードはロックされます。
ポータル行のフィールドに編集を行って確定せずに他の行も編集すればそちらもロックされます。
一括ロックする方法は#7で示したとおり、
ポータルの各行で[レコード/検索条件を開く]を実行すれば可能です。
一見すると[レコード/検索条件を開く]は親レコードを開くように思われますが
この場合はポータル各行の関連レコードを開く動作をします。
以下の様になります。
オブジェクトへ移動 [ オブジェクト名: "ポータル" ]
# ポータル行数(関連レコード数)をカウント
変数を設定 [ $行数 ; 値: Count ( 子::__id ) ]
ポータル内の行へ移動 [ 選択: オン ; 最初の ]
Loop
レコード/検索条件を開く
Exit Loop If [ Get ( アクティブポータル行番号 ) = $行数 ]
ポータル内の行へ移動 [ 選択: オン ; 次の ; 最後まできたら終了: オン ]
End Loop
追加の検証ではデカルト積での自己リレーションでも有効でした。
ただし「現在のテーブル」のポータル(リレーションを使わない)では効きません。
サンプルも更新しました。(URLは同じです)
http://bit.ly/2JirP5A
Last edited by Moz (2019-05-14 13:22:26)
Offline
実際に編集開始するまでロックされないということであって、親でもポータル内のどの行でも、1か所で入力し始めれば、全部の関連行がロックされます。
レイアウト上でポータルのいずれかの行を入力開始すると
他のウインドウや他のクライアントからは同じレイアウトで同じレコードを変更することはできません。
この状態が #11 ですがこれは明細行がロックされているのではなく親レコードがロックされているだけです。
同じレイアウトでは編集ができませんが子レコードだけのレイアウトからは
編集中の明細行に該当する子レコード以外は編集可能です。
Offline
げげ。そうなんですか。
今までロック機能に使ってた人から苦情が来なかったのかなあ?
緩い楽観的排他と表現する方もいらっしゃいますが、#11 の排他で充分だからかと。
ポータルを利用したレイアウトは「注文」と「注文明細」のような関係で利用されると思います。
データへのアクセス口となるレイアウトは「注文」となりますから #11 の排他制御が行われれば
同じ注文を複数の人間が変更して発生する不整合は充分に防げるでしょう。
「注文明細」をレイアウトに割り当てるのは帳票・集計などでしょうから
そのレイアウトではレコードのデータ編集を許す必要性も少ないと考えられます。
顧客の過去の注文履歴などではポータル内も別の親のこともありますが、
この場合はポータル内の行が変更されても運用上問題ではないでしょう。
今回ポータルを利用してロックしたい目的はよく分かりませんが、
対象レコードをすべてロックする必要があるのは例えば対象レコードすべてに一斉に処理をする際に
レコードをすべてロックして他の人が変更できない様にする等でしょうか。
ここまで排他をせずにループや全置換で行っているのが実情ではないかと思います。
最初の質問の②の質問の答えですが、他の方が編集中でエラーの場合はエラー301が返ります。
Last edited by Moz (2019-05-14 15:12:43)
Offline
皆様ありがとうございます。
デモファイル、助かりました!
現在の仕様では複数レコードの一括ロックが簡単にできないのは残念ですがそれが分かって良かったです。
デモファイルを見て思ったのですが対象レコードをロックしようと思ったら
集計フィールドで現在の対象レコードのIDリストで自己リレーションしたレコードをロックする感じでしょうか?
そもそも論として複数レコードの一括ロックが必要なケースというのが稀でしょう。
後学のために伺うと何のために一括ロックしたいのでしょうか?
現在の仕様の理由などを理解するために FileMaker のラーニングセンターから教書として
無料の FileMaker Master Book をダウンロードして読まれることをお勧めします。
https://www.filemaker.com/jp/learning/
仕様がダメ(要望に添わない) = FileMaker がダメではないので
これが分からないと折角の FileMaker との出会いを無駄にしてしまいます。
デモファイルでは集計フィールドを一括ロックでは利用していません。
※集計フィールドはリレーションの照合フィールドにできません。
一括ロックは #10 で示したスクリプトステップで実現しています。
なぜロックが掛かるのか考えながら見られると良いでしょう。
まずは体系的に初歩から学習されることを強く推奨します。
Offline
申し訳ございません。
現在、ファイルメーカーに出会って半年ほどなのですがシステム開発の仕事に携わっております。
以前、上司に現在の社内システムでは複数ユーザーと処理がぶつかったときのことは考えていないと言われたことがありまして
ファイルメーカーで排他というものはどうやって行うのか調べておりました。
一応 FileMaker Master Bookは初級だけですが目を通しております。
まだまだ基礎ができてない状態なのでお恥ずかしい限りです。
申し訳ございません。説明不足でした。
テキストタイプのグローバルフィールドにIDの一覧を入れて自己リレーションのことです。
そもそも論として複数レコードの一括ロックが必要なケースというのが稀でしょう。
後学のために伺うと何のために一括ロックしたいのでしょうか?現在の仕様の理由などを理解するために FileMaker のラーニングセンターから教書として
無料の FileMaker Master Book をダウンロードして読まれることをお勧めします。
https://www.filemaker.com/jp/learning/
仕様がダメ(要望に添わない) = FileMaker がダメではないので
これが分からないと折角の FileMaker との出会いを無駄にしてしまいます。デモファイルでは集計フィールドを一括ロックでは利用していません。
※集計フィールドはリレーションの照合フィールドにできません。一括ロックは #10 で示したスクリプトステップで実現しています。
なぜロックが掛かるのか考えながら見られると良いでしょう。まずは体系的に初歩から学習されることを強く推奨します。
現在の社内システムが FileMaker で作られているとしたら特に意識しなくても
同じレコードを複数人で変更できない様に排他制御されています。
レイアウト上にポータルがあるとしても #11 に書かれているとおり
親を通して子をロックしますから複数人で同じ親レコードのポータル行を編集することはできません。
どのようなシステムになっているか不明ですが、
ポータルの1行1行の中のレコードをわざわざ編集するような機能を作っていなければ無用な心配でしょう。
サンプルでは他テーブルでは主キーと外部キーを使った一般的なリレーション、
同一テーブルではデカルト積「x」リレーションを利用した全対全のリレーションです。
グローバル格納とIDの一覧(改行区切り)によるリレーションも用いていません。
→ポータルを利用した一括ロックの手法であって、対象レコードをポータルに表示するための手法ではありません。
※その場合でもロックする手法は同じですが......
複数人での衝突を避けるために任意のレコードを検索して予め一括ロックする必要があるのですか?
その場合はどのユーザを優先するのかなどの運用ルールといった別の問題が出るわけですが(汗
Offline
最近、全件あるいは対象レコードをフィールドの置換を用いて処理する必要が多少あったため質問させていただきました。
複数人での衝突を避けるために任意のレコードを検索して予め一括ロックする必要があるのですか?
その場合はどのユーザを優先するのかなどの運用ルールといった別の問題が出るわけですが(汗
それならば Loop を利用してフィールド設定していけば良いでしょう。
排他によって処理できなければエラー301が返りますからIDなどを記録しておき、
エラーだったレコードに再試行すればすみます。
一括ロックでも誰かが使用中ならばロックから漏れるので同じことです。
ロックかかるまで再試行するのと置換のみを再試行ではどちらが良いか自明です。
全置換はエラーレコードの特定が難しいため非推奨です。
※誰もいない時間にやれば全置換でも可。
Offline
ご返信遅くなり申し訳ございません。
エラーのみ再試行とありますがエラーのレコードが他のユーザーがそのレコードをずっと開いたままの場合は処理できないと思うのですが
こういった場合はどのように処理されてるんでしょうか?
それならば Loop を利用してフィールド設定していけば良いでしょう。
排他によって処理できなければエラー301が返りますからIDなどを記録しておき、
エラーだったレコードに再試行すればすみます。一括ロックでも誰かが使用中ならばロックから漏れるので同じことです。
ロックかかるまで再試行するのと置換のみを再試行ではどちらが良いか自明です。全置換はエラーレコードの特定が難しいため非推奨です。
※誰もいない時間にやれば全置換でも可。
Offline
編集が終わってから再処理、またはその場で声がけをして一旦編集を終えて貰って再処理と様々でしょう。
一括処理とユーザの編集の優先度などは「運用ルール」ですから質問者さんと所属の組織で考えることです。
一括処理が必要なのはどんな処理なのか、一過性なのか継続性なのかでも変わります。
一過性ならばわざわざ誰かが触ってそうな時間にやらず誰も触っていない時間に処理すれば済む話です。
継続性の処理の場合
ユーザが編集中でエラーになるレコードが頻発するならば処理をする時間帯が適切ではない可能性もあります。
誰かが触っている最中でも一括処理が必要になる運用というのは適切とは考えづらいでしょう。
例えばチェックを入れるだけで全置換をしているならば代替手段を検討しても良いかも知れません。
何のためにどのような一括処理をしているのか分からない状態ではどのような対処が良いという答えは出ません。
※先述しましたが最終的な運用ルールは私たちアドバイス側が考えることではありません。
Offline
横ですが先日似たような悩みを抱えてました。
同じように古い記事を参考にポータル親排他を試行錯誤しましたが
無理な理由が解り納得しました。
知り合いの会社さんがFMシステムで注文管理(仮引当)と在庫の入出管理(一括で発送引当処理、仕入処理)を
されていたのですが、たまに引当が出来てないとの事で相談を受けて、
調べた所、注文入力の頻度が高く、在庫側が商品数を一括登録する場合に排他が掛かっていて
引当出来ない事がわかりました。
仕方ないのでLOOPで回して、排他が掛かったものをエラー処理でプールし対処しましたが
数商品ならLOOPでも速いですが、かなりの数の在庫入出があったので、
LOOPだとやはり時間が掛かってしまうようでした。
Pages: 1
[ Generated in 0.006 seconds, 9 queries executed - Memory usage: 583.25 KiB (Peak: 620.16 KiB) ]