みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
計算フィールドは、ほとんどがリレーション先を参照していますので、非保存になっています。
経由店の変更が発生する時は、明細順の変更がついてきますので、その設定と同時に自動入力のルックアップで値を持たせれば、保存にできます。構造はそのままでいいです。
ちょこっと触ったサンプルファイルに入れ替えています。
Last edited by Shin (2023-12-21 09:52:14)
Offline
みなさまのおかげでトリガーを設定して対応しております。
派生した質問になります。
やはり警告的な表示は多少は必要と思っております。
リレーション先のテーブルを参照して結果を得て
文字を赤くしたりしたい場合
①条件付き書式
②次の場合にオブジェクトを隠す
ソートした際に遅くなりにくいのはどちらって決まっていますか？
運用としてはどちらでも可能です。
どちらがリスト形式でソートなど行った時に影響が大きいのかなと思いまして。
Offline
実ファイルをみてみないとわからないでしょう。余り差はないと予想しますが。
新しいサンプルはみてみました？
Offline
余り差は無いということはどちらのパターンもリスト形式で表示される度に再評価しているということですかね？
サンプルを拝見しましたが若干派生してましたので違う話になってしまいすみません。
警告というかどう視覚的に見せるかなんですが。
例えば配達日が入力されている場合はグレーアウトさせるとか。
中継の配達日がまだの場合は続きの配送に未着マークをつけるとか。
とある発地の場合だけ緑に塗りつぶしたいとか。
そういったリスト形式で見た時に見やすくするためにしたいことが発地・着地の相違以外にも
結構あったので・・・条件付き書式か隠すかどっちが重たくならないかなと思いまして。
ちなみに結構な社外秘なので公にはできないファイルをshinさんだけに見て頂く手段はございますか？
Offline
案件毎の状態を持たせておくフィールドを作っておき、それを随時(中継点通過など)の入力で更新していくなどで対処できるのでは。そのようなマルチな動きには、条件付き書式を使うでしょう。
名前をクリックすれば、直接メールを送るリンクがあります。
Offline
なるほど、リレーションを巡らす前にそのテーブルで必要なフラグを立てて
そのフラグを条件付き書式すればそこまで重たい評価にはならないということですね。
今メールを送らせて頂きました。
Offline
元テーブルを触るのが気持ち悪いでしょうから、それと1対1の別テーブルを作り、そこに状態フラグを持たせるのがいいででしょう。動きも軽くなります。
#8に戻りますが、色々なチェックのためのリレーションが多用されているようですが、これが遅くなっている原因とも考えられます。リレーションは、関連先のレコードを絞り込む動作が入りますので、どうしても遅くなってしまいます。特に、重複レコードのチェックがあるようですが、それが発生しないような何らかの方策を取られれば、かなり軽くなるのでは無いかと思います。（対象になるレコードが相当数になりますので）具体的には、メインのレコードを確定するまではトランザクション処理を使って確定させず、確定動作でユニークを確認するような動作とする、または。ユニークレコードの基準となっているフィールドを結合させた自動計算のフィールドを作っておき常時ユニーク制限をつけるなどを行えばいいでしょう。
Offline
shinさんありがとうございます。
1対1の別テーブル
という言葉をすみませんいまいち理解できていません。
もう少し解説お願いできればと存じます。
重複の検知ですね。
ユニークレコードの基準となっているフィールドを結合させた自動計算のフィールドを作っておき
↑
この自動入力のフィールドはありまして、そこを自己リレーションしてカウントが2以上で強調表示にしてます。
ユニーク制限は理解できるのですが
インポートの時はエラーでスキップされますよね？
200件くらいインポートする時があるんですが
いつも思うんですが何がスキップされたか特定するのが困難なんですよね。
特定してお客様に指摘する必要がありますので・・・
Offline
> 1対1の別テーブル
案件ごとのユニークなフィールドでリレーションを持たせた別テーブルを作ります。そこに、リレーションキーのフィールドを、案件の状態（運送のようですので、現在の荷物の位置など）のフィールドを作ります。
中継点を通過する入力時に、そのフィールドも更新します。（ルックアップの設定で作れるかもしれません）
リストからは、その状態フィールドを参照した諸式表示にするといいです。
> 重複の検知ですね。
> いつも思うんですが何がスキップされたか特定するのが困難なんですよね。
中間テーブルを作っておき、一旦そこと本テーブルにインポート、本テーブルから中間テーブルへ関連テーブルへ移動します、対象外のレコードが重複したものです。中間テーブルは運用に間径ないデータですので、別ファイルにしておき、不要レコードは削除していく運用でもいいでしょうね。
Offline
案件ごとにIDがあるのでユニークフィールドはあります。
ID111 東京～中継A 12/18 田中さん
ID115 中継A～中継B 12/22 佐藤さん
ID119 中継B～福岡
こういった手配詳細が3行ある場合
本日12/22にID119を見た時に
×未着
△今日到着
〇到着済
というフラグで△になって欲しいのですが
自己リレーションした場合実際どのようなキーを結んだら取得できますか？
重複の件は試してみます。
勉強になりました中間テーブル経由。ありがとうございます。
Offline
私の言っている案件は、上の例で言うと、東京→福岡 という概念です。それを、ID11 としておき、ID11をキーとするリレーションしたテーブルを作ります。
ID111 ID115 ID119 を、それぞれ1 2 3 という順次番号をつけておきます。（ID が時系列でつくのでしたら、それでもいいです）
現在、中継Aを出発しているので状態偏移pを 2 とし、それをテーブルに保存します。ですから、ID111（p1） からpをみると自分より上が設定されているので済み、ID115（p2） からみると、自分と同じなのでこのフェーズとなり到着予定、ID119（p3）からみると、下が設定されているので未着、というシンプルに判断できます。
そのpは編集頻度が高いので、小さなテーブルに置く方が効率がいいですし、案件が終了（最終到着後）したら削除してもいい値ですので、元案件とID11をキーとするリレーションしたテーブルに持たせておいたほうがいいと思います。
Last edited by Shin (2023-12-22 16:22:49)
Offline
Shinさんありがとうございます。
少し考えて構築してみます。
別件で見て頂いたファイルの質問を1つだけしてもよろしいでしょうか？
登録メインの発地と着地や種別など
詳細と不一致なら変更するスクリプトトリガを設定しています。
うまく機能はしているんですが
トリガにて動作終了後に次のフィールドへタブ移動してしまうのは仕様ですか？
普段の入力業務でタブ移動はすごく便利ですが
スクリプトトリガが動作して目的のフィールドが書き換えられた時に
次のフィールドへ移動するのは不便です。
デバッガで追うと
スクリプトステップの最後にレコード確定を入れてもそのスクリプトが
終了した後に次のフィールドに移動してしまうので
諦めるしかないのかなと思っております。
何かご存知でしたら幸いです。
Offline
ファイルのどの部分かはみていませんが。（非常に大きなファイルですので、きちんと内容を把握するには数ヶ月以上かかります。請負業務ですと、特に仕様書が無い場合は、ここに数百万以上の相当の費用が発生します）
スクリプトトリガーが起動したスクリプトが終了した時の動作は、そのスクリプトが無かったものとして動作しますので、例えばフィールドを設定して確定すると次のフィールドへ移動 することになります。それを、スクリプトが終了した時点での動きで止めるためには、スクリプトを終了させ、その結果に0を設定します。これによって、スクリプトが終了したあとの動作をキャンセルできます。
> 登録メインの発地と着地や種別など詳細と不一致
これは、同じ値にならないといけないものを独立した２フィールドで管理してしまっている、設計上の問題です。
先に挙げている私のサンプルではそのような事態は起こりません。ここの改造は簡単ですので、手をつけられればいかがでしょう。構造を変更すればベストでしょうが、フィールドの制限でエラーを出すことは可能です。
Last edited by Shin (2023-12-23 09:47:04)
Offline
そのスクリプトが無かったものとして動作します
＞そういうことだったんですね。
つまりスクリプトステップの最後にスクリプトを終了を意図的に作ればいいということですか？
その結果に0を設定が少し理解できてなくて間違っていたらすみません。
> 登録メインの発地と着地や種別など詳細と不一致
こちらは10年この運用で他の色々な要素を踏まえるとshiさんの構造に変更するのは支障がでるかと思います。
可能かとは思うのですが質問させていただく内容が増えてしまいそうなので控えておきます。
フィールドの制限というのも考えなかったですね。
計算式で制限ですよね？少しやってみます。
色々とありがとうございます。
Offline
実務上の作業は、発店から次の中継点を探して行って、着店に辿りつかせる、という考え方なのでしょうね。私の考え方は、発店から着店へ腺を張って、その途中に中継点を設定していく、という考え方です。実務に合わせて参考になさってください。
構造の変更については、最初の設計思想を変える事になるので、簡単には対応できないと思います。
ファイルの構成そのものが古くなり、業務改革などに合わせて大きく更新する必要が出てくる頃だと思います。それに合わせて作りなおされるといいと思います。
Offline
[ Generated in 0.012 seconds, 10 queries executed - Memory usage: 558.02 KiB (Peak: 578.55 KiB) ]