みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
度々の質問で申し訳ございません。
WIN10
FM cloud
FM20
クライアントが各案件を選択して「絞込」ボタンで好きな案件を絞りこめるようにしています。
テキストフィールド：「チェック挿入」
IF 「チェック挿入」が空欄の場合
Left ( Get ( アカウント名 ) ; Position ( Get ( アカウント名 ) ; "@" ; 1 ; 1 )-1 )
空欄じゃなければ""に。
というボタン設定をして
これでチェック挿入フィールドにクラリスIDの＠より手前を挿入しています。
この挿入にかかる時間がリスト形式のレコードで1行の時と
500行くらいある時とで3倍くらいテキストが挿入される時間がかかります。
ポンポンクリックして選択していくので遅いとテンポが狂って調子悪いと言われました・・・
チェック挿入フィールド内容が空白でも誰かの＠手前が入っていても
そこを評価する計算式や条件付書式・ソートはかかっておりません。
なぜこんなに時間差がでるのでしょうか。
早くなる方法ありますでしょうか。
ちなみにGet(アカウント名)が遅いのかと思いファイルを開いた時点で
グローバルフィールドに＠手前を持たせておいてそのフィールド内容を挿入する、というのは試しましたが
体感は何も変わりませんでした。
Offline
あとリスト形式の表示速度の件で関連した質問ですが
条件付き書式の使い過ぎは表示速度に影響すると言われていますが
①条件付き書式で特定のフィールドを塗りつぶす
②フィールド前面に半透明の四角いマスを配置して「次の場合にオブジェクトを隠す」を使って塗りつぶされているように見せる
これはどちらが早いかどなたかご存じですか？
Last edited by mirai (2023-12-09 15:51:40)
Offline
それだと、他人が選択してたものを解除してしまう動作になってませんか？
グローバルフィールドに、選択した案件のIDをリスト形式で保存するのがいいと思います。
ただしグローバルフィールドはサインアウトするとクリアされるので、次回以降も選択状態を保存したければアカウントごとにレコードを作って選択した案件を保存するテーブルを使います。
あぁ間違えて他人の選択を解除することはあります笑
でもそこは問題ありません。
むしろ他人のチェックがあるから自分がチェックできない方が問題で
普段から声かけしてチェックもらうよ～って言いあってるので問題ありません。
あとグローバルフィールドはファイルオプションで開いた時点でスクリプトで挿入されるようにしてるので
開いている間は保持されてるので問題ないかと思います。
Offline
他人と完全に独立してチェックできる仕組みは作れますよ。
全体リストをポータルで表示しておいて、案件にチェックするだけで自分のリストを作れます。チェックを付けても外しても、別のアカウントとは独立して動きますし、並行しての動きも可能です。また、何百レコードあろうとも、動きは瞬時です。
動きだけのサンプルです。（細かいエラーチェックなどはしていませんし、自分の該当レコードが無いとリストが表示されず、チェックもできなくなりますので、御注意を。手動で案件リストのアカウントに追加設定し直してください）
https://www.dropbox.com/scl/fi/6usstf8g … qbnn3&dl=0
Offline
SHINさんありがとうございます。
参考にさせていただいたんですが従来の自身の方法でいこうと思うのですが。
今まったく同じレイアウトを作成して
そこにある条件付き書式と「次の場合にオブジェクトを隠す」を全て解除しました。
すると驚くほどスピーディに@手前のアカウント名が挿入されました。
ここまで明確に変わると原因はここしか無いと思うのですが
条件の中にチェック挿入は無いのに影響するのでしょうか？
レコード条件確定する際に全ての条件付き書式が再評価されているからということですかね？
だとすると遅くなるのは目に見えてるので条件付き書式と「次の場合にオブジェクトを隠す」を諦めるしかないのですが。
諦めると視覚的にすごく不便なのでどうしたらいいでしょうか・・・
Last edited by mirai (2023-12-09 16:59:07)
Offline
担当が変わるというチェックなのでしたらその運用でもいいでしょうが、トラブルになるかもしれませんよ
遅くなっている原因がわかっているので、それ以上はそれをみて考えるしかないのでは。そのためには、ファイルそのものを見せていただけると早いでしょうね。
その条件式を書き出してみてください。
Last edited by Shin (2023-12-09 22:13:14)
Offline
車の輸送（キャリアカーで車その物を運んでます）
車体登録→メイン登録のテーブル
陸送手配→配車をするテーブル
イメージとしてはA→Bに運ぶがメインの請求となる動き
陸送手配のテーブルでは中継があるので配車としてはA→B→Cという動きになります。
車体登録のレイアウトにポータルで陸送手配を新規レコード追加で詳細な陸送手配を追加していっております。
①車体登録::急ぎ便フラグ = "お急ぎ便"
リレーション先の車体登録に輸送を急ぐフラグがあり該当すると水色に塗りつぶし
②not IsEmpty ( 車体登録::完了日 )
リレーション先の車体登録で請求を上げらる状態の輸送完了となっている場合はピンクに塗りつぶし
③not IsEmpty ( 会場警告車体登録::搬出会場コード )
④会場不一致搬入降順::搬入会場 ≠ 会場不一致搬入降順キー::搬入会場
⑤会場不一致搬出昇順::搬出会場 ≠ 会場不一致搬出昇順キー::搬出会場
⑥Count ( 重複レコード検知::管理コード ) < 2
↑これは「次の場合にオブジェクトを隠す」です。
③～⑥はすみません文章で説明するのが難しいんですが
入力した内容のミスを赤くして指摘するようなイメージの警告です。
アドバイスいただけたら幸いです。
Offline
リレーションの設定で大きく変わりそうです。
Offline
リレーションが複雑なのが要因ですかね？
Offline
理解し切れてませんが、「会場不一致搬入降順」という名前からしてリレーションをソートしてるでしょうから、そこが原因の気がします。（FMは検索は索引を使って早いですが、ソートが遅いです）
リレーションがかなり複雑になっていそうですね。himadaneeさんも指摘されているのですが、リレーションごとのソートが相当負荷が大きくなっていそうです、
Offline
himadaneeさん
shinさん
ありがとうございます。
確かにソートがかかっているリレーションになってますね。
であればリレーション先のテーブルで「不一致」を入力の過程でフィールドを作って警告することは可能ですので
そこを作ってしまえばソートの無いリレーションができます。
そちらで試してみようと思います。
ソートといってもリレーション先には3レコードくらいしか平均的には無いリレーション先だったので
こんなに不可が大きいとは思ってませんでした。
Offline
逆に、不一致を判断する必要がある、ということは、レコードが2重になっている、ということでしょうね。そこを改修すればかなりシンプルになると思いますが。
Offline
その部分の相談で言うと
テーブルA メイン登録
テーブルB 手配詳細
メイン登録をしたあとに同レイアウトで詳細へボタンスクリプトにて反映させてポータルが出来上がる仕様にしてるんですが
例えばAからBに運ぶ
詳細ポータルまで出来上がってる
このタイミングでBではなくやっぱりCに運んで。という変更が生じます。
メイン登録のBをCに変更した時にダイアログで
「詳細ポータルの方も変更してね！」というダイアログは出してるんですが惰性でクリックしてしまい変更のし忘れがあります。
変更し忘れた状態で詳細だけ見て手配すると運ぶ先を間違えてしまうので条件付き書式で警告するようにしてました。
メイン登録の変更をした時にトリガーでポータルの着地点も変更するように自動化を考えようと思います。
逆もしかりです。発地点も同様な事が発生してました。
ですが
メイン登録の発着が
A→Bの場合
場所によっては手配詳細は
A→E(経由地)
E→B
というポータルを作成しています。
この時にBがCに変更になると自動で
A→EのEは変更せずに
E→BのBだけCに変更するのはどうしたらいいんでしょうか。
ポータルの手配詳細テーブルは1～連番にシリアルを振ってあるので
降順にしておけばいつも1番目が最終着地にはなってますが。。。
Offline
手配詳細は
E(経由地)
だけを登録しておけばいいのでは。
AとかBは、シリアルを使って計算で出せますよね。
詳細の行数が2行でないと不都合なら（つまり経由がない場合に詳細が1行）、メイン登録の着の方は入力せず計算で出す。
himadaneeさんありがとうございます。
計算で出せますがAとＢはそのレコードが自分が経由のレコードなのか発地に関連したレコードなのか着地に関連したレコードなのかは導くことが出来ないように思うのですが。。。
伝えてなくてすみませんが経由は最大で5になります。
A→B
B→C
C→D
D→E
E→F
AからFでB～Eを経由する。
最大でこのくらい詳細としては変動します。
かつ、法則はなくケースバイケースです。
Offline
>ポータルの手配詳細テーブルは1～連番にシリアルを振ってある
1番が発で最後が着ではないんですか？
そうです。
ですが計算値自動入力ってメイン登録打ち換えただけではポータル内のフィールドで更新されないですよね？
詳細のAからFは全て索引設定していて実績の集計などいろいろなとこに参照されているので
できれば現状のフィールドとして運用したいところですが・・・
Offline
＞AからFでB～Eを経由する。
この場合経由は４ではないか、というのが＃１６の考え方（A～Fで6か所あって、発着を除くので）ですが、５というのが必要なら色々根本的な変更になってしまうので無理そうですね。
＞メイン登録のBをCに変更した時に
onRecordCommitのトリガで変更されてるか確認・自動修正するのが無難でしょうかね。
onRecordCommitですね。
トリガーで補正できるようにいろいろしてみます。
ありがとうございます。
Offline
全く構造が異なると思いますが、レコードのコピペやインポートなど全く行わない構造です。中継地点の追加なども簡単に行えます。
https://www.dropbox.com/s/bgs3fzqt615jv … 2.zip?dl=0
Last edited by Shin (2023-12-12 13:38:53)
Offline
Shinさんありがとうございます。
参考にさせて頂きます。
ちなみに着点が勝手にメインを変えた時に反映されるのは
トリガーが何も無く計算フィールドでもないようですがそういった原理ですか？
教えて頂けると幸いです。
Offline
リレーションを通して、着店そのものを書き換えていますよ。
全く発想を変えていますので、ほぼ同じ動きを実現させているはずですが、極めてシンプルな構造でしょ。
Last edited by Shin (2023-12-11 16:31:54)
Offline
ボタン設定で着店に入力するようになっていたんですね！
紐解くと計算式が非保存で行われていますね。
テクニックがすごく勉強になりましたが発・着ともにメインも詳細のテーブルも索引が必要なんですよね・・・
集計もソートも毎日の使用頻度は代表格なので。
Offline
[ Generated in 0.008 seconds, 8 queries executed - Memory usage: 575.46 KiB (Peak: 612.37 KiB) ]