みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
そのスクリプトが無かったものとして動作します
＞そういうことだったんですね。
つまりスクリプトステップの最後にスクリプトを終了を意図的に作ればいいということですか？
その結果に0を設定が少し理解できてなくて間違っていたらすみません。
> 登録メインの発地と着地や種別など詳細と不一致
こちらは10年この運用で他の色々な要素を踏まえるとshiさんの構造に変更するのは支障がでるかと思います。
可能かとは思うのですが質問させていただく内容が増えてしまいそうなので控えておきます。
フィールドの制限というのも考えなかったですね。
計算式で制限ですよね？少しやってみます。
色々とありがとうございます。
Shinさんありがとうございます。
少し考えて構築してみます。
別件で見て頂いたファイルの質問を1つだけしてもよろしいでしょうか？
登録メインの発地と着地や種別など
詳細と不一致なら変更するスクリプトトリガを設定しています。
うまく機能はしているんですが
トリガにて動作終了後に次のフィールドへタブ移動してしまうのは仕様ですか？
普段の入力業務でタブ移動はすごく便利ですが
スクリプトトリガが動作して目的のフィールドが書き換えられた時に
次のフィールドへ移動するのは不便です。
デバッガで追うと
スクリプトステップの最後にレコード確定を入れてもそのスクリプトが
終了した後に次のフィールドに移動してしまうので
諦めるしかないのかなと思っております。
何かご存知でしたら幸いです。
案件ごとにIDがあるのでユニークフィールドはあります。
ID111 東京～中継A 12/18 田中さん
ID115 中継A～中継B 12/22 佐藤さん
ID119 中継B～福岡
こういった手配詳細が3行ある場合
本日12/22にID119を見た時に
×未着
△今日到着
〇到着済
というフラグで△になって欲しいのですが
自己リレーションした場合実際どのようなキーを結んだら取得できますか？
重複の件は試してみます。
勉強になりました中間テーブル経由。ありがとうございます。
shinさんありがとうございます。
1対1の別テーブル
という言葉をすみませんいまいち理解できていません。
もう少し解説お願いできればと存じます。
重複の検知ですね。
ユニークレコードの基準となっているフィールドを結合させた自動計算のフィールドを作っておき
↑
この自動入力のフィールドはありまして、そこを自己リレーションしてカウントが2以上で強調表示にしてます。
ユニーク制限は理解できるのですが
インポートの時はエラーでスキップされますよね？
200件くらいインポートする時があるんですが
いつも思うんですが何がスキップされたか特定するのが困難なんですよね。
特定してお客様に指摘する必要がありますので・・・
なるほど、リレーションを巡らす前にそのテーブルで必要なフラグを立てて
そのフラグを条件付き書式すればそこまで重たい評価にはならないということですね。
今メールを送らせて頂きました。
余り差は無いということはどちらのパターンもリスト形式で表示される度に再評価しているということですかね？
サンプルを拝見しましたが若干派生してましたので違う話になってしまいすみません。
警告というかどう視覚的に見せるかなんですが。
例えば配達日が入力されている場合はグレーアウトさせるとか。
中継の配達日がまだの場合は続きの配送に未着マークをつけるとか。
とある発地の場合だけ緑に塗りつぶしたいとか。
そういったリスト形式で見た時に見やすくするためにしたいことが発地・着地の相違以外にも
結構あったので・・・条件付き書式か隠すかどっちが重たくならないかなと思いまして。
ちなみに結構な社外秘なので公にはできないファイルをshinさんだけに見て頂く手段はございますか？
みなさまのおかげでトリガーを設定して対応しております。
派生した質問になります。
やはり警告的な表示は多少は必要と思っております。
リレーション先のテーブルを参照して結果を得て
文字を赤くしたりしたい場合
①条件付き書式
②次の場合にオブジェクトを隠す
ソートした際に遅くなりにくいのはどちらって決まっていますか？
運用としてはどちらでも可能です。
どちらがリスト形式でソートなど行った時に影響が大きいのかなと思いまして。
ボタン設定で着店に入力するようになっていたんですね！
紐解くと計算式が非保存で行われていますね。
テクニックがすごく勉強になりましたが発・着ともにメインも詳細のテーブルも索引が必要なんですよね・・・
集計もソートも毎日の使用頻度は代表格なので。
Shinさんありがとうございます。
参考にさせて頂きます。
ちなみに着点が勝手にメインを変えた時に反映されるのは
トリガーが何も無く計算フィールドでもないようですがそういった原理ですか？
教えて頂けると幸いです。
onRecordCommitですね。
トリガーで補正できるようにいろいろしてみます。
ありがとうございます。
そうです。
ですが計算値自動入力ってメイン登録打ち換えただけではポータル内のフィールドで更新されないですよね？
詳細のAからFは全て索引設定していて実績の集計などいろいろなとこに参照されているので
できれば現状のフィールドとして運用したいところですが・・・
himadaneeさんありがとうございます。
計算で出せますがAとＢはそのレコードが自分が経由のレコードなのか発地に関連したレコードなのか着地に関連したレコードなのかは導くことが出来ないように思うのですが。。。
伝えてなくてすみませんが経由は最大で5になります。
A→B
B→C
C→D
D→E
E→F
AからFでB～Eを経由する。
最大でこのくらい詳細としては変動します。
かつ、法則はなくケースバイケースです。
その部分の相談で言うと
テーブル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番目が最終着地にはなってますが。。。
himadaneeさん
shinさん
ありがとうございます。
確かにソートがかかっているリレーションになってますね。
であればリレーション先のテーブルで「不一致」を入力の過程でフィールドを作って警告することは可能ですので
そこを作ってしまえばソートの無いリレーションができます。
そちらで試してみようと思います。
ソートといってもリレーション先には3レコードくらいしか平均的には無いリレーション先だったので
こんなに不可が大きいとは思ってませんでした。
リレーションが複雑なのが要因ですかね？
車の輸送（キャリアカーで車その物を運んでます）
車体登録→メイン登録のテーブル
陸送手配→配車をするテーブル
イメージとしてはA→Bに運ぶがメインの請求となる動き
陸送手配のテーブルでは中継があるので配車としてはA→B→Cという動きになります。
車体登録のレイアウトにポータルで陸送手配を新規レコード追加で詳細な陸送手配を追加していっております。
①車体登録::急ぎ便フラグ = "お急ぎ便"
リレーション先の車体登録に輸送を急ぐフラグがあり該当すると水色に塗りつぶし
②not IsEmpty ( 車体登録::完了日 )
リレーション先の車体登録で請求を上げらる状態の輸送完了となっている場合はピンクに塗りつぶし
③not IsEmpty ( 会場警告車体登録::搬出会場コード )
④会場不一致搬入降順::搬入会場 ≠ 会場不一致搬入降順キー::搬入会場
⑤会場不一致搬出昇順::搬出会場 ≠ 会場不一致搬出昇順キー::搬出会場
⑥Count ( 重複レコード検知::管理コード ) < 2
↑これは「次の場合にオブジェクトを隠す」です。
③～⑥はすみません文章で説明するのが難しいんですが
入力した内容のミスを赤くして指摘するようなイメージの警告です。
アドバイスいただけたら幸いです。
SHINさんありがとうございます。
参考にさせていただいたんですが従来の自身の方法でいこうと思うのですが。
今まったく同じレイアウトを作成して
そこにある条件付き書式と「次の場合にオブジェクトを隠す」を全て解除しました。
すると驚くほどスピーディに@手前のアカウント名が挿入されました。
ここまで明確に変わると原因はここしか無いと思うのですが
条件の中にチェック挿入は無いのに影響するのでしょうか？
レコード条件確定する際に全ての条件付き書式が再評価されているからということですかね？
だとすると遅くなるのは目に見えてるので条件付き書式と「次の場合にオブジェクトを隠す」を諦めるしかないのですが。
諦めると視覚的にすごく不便なのでどうしたらいいでしょうか・・・
あぁ間違えて他人の選択を解除することはあります笑
でもそこは問題ありません。
むしろ他人のチェックがあるから自分がチェックできない方が問題で
普段から声かけしてチェックもらうよ～って言いあってるので問題ありません。
あとグローバルフィールドはファイルオプションで開いた時点でスクリプトで挿入されるようにしてるので
開いている間は保持されてるので問題ないかと思います。
あとリスト形式の表示速度の件で関連した質問ですが
条件付き書式の使い過ぎは表示速度に影響すると言われていますが
①条件付き書式で特定のフィールドを塗りつぶす
②フィールド前面に半透明の四角いマスを配置して「次の場合にオブジェクトを隠す」を使って塗りつぶされているように見せる
これはどちらが早いかどなたかご存じですか？
度々の質問で申し訳ございません。
WIN10
FM cloud
FM20
クライアントが各案件を選択して「絞込」ボタンで好きな案件を絞りこめるようにしています。
テキストフィールド：「チェック挿入」
IF 「チェック挿入」が空欄の場合
Left ( Get ( アカウント名 ) ; Position ( Get ( アカウント名 ) ; "@" ; 1 ; 1 )-1 )
空欄じゃなければ""に。
というボタン設定をして
これでチェック挿入フィールドにクラリスIDの＠より手前を挿入しています。
この挿入にかかる時間がリスト形式のレコードで1行の時と
500行くらいある時とで3倍くらいテキストが挿入される時間がかかります。
ポンポンクリックして選択していくので遅いとテンポが狂って調子悪いと言われました・・・
チェック挿入フィールド内容が空白でも誰かの＠手前が入っていても
そこを評価する計算式や条件付書式・ソートはかかっておりません。
なぜこんなに時間差がでるのでしょうか。
早くなる方法ありますでしょうか。
ちなみにGet(アカウント名)が遅いのかと思いファイルを開いた時点で
グローバルフィールドに＠手前を持たせておいてそのフィールド内容を挿入する、というのは試しましたが
体感は何も変わりませんでした。
みなさんありがとうございました。
shinさんのwhile()で無事に思った結果が出ました！
ver14で時が止まっておりましたので感動しました。
ありがとうございました。
できれば集計フィールドを作るのは避けたいところで悩んでおります。
フィールドを増やさずにできる方法はありますでしょうか。
実はこの過程は変数に設定して別のフィールドに展開する一コマです。
なので変数として設定する計算で出来ればいいなと思っていたんです。。。
すみませんお返事遅くなりました！
参考にさせて頂いてやってみます！
自己リレーションでやってみようかなと思うんですが
リストの元のテーブルで自己リレーションして、
計算フィールド
エリア & ":" Count ( 自己リレーション::エリア )
として、
これのユニークなリストを得ればできますね。
このユニークなリストを得るというのはどういった処理をすれば可能ですか？
いつも参考にさせて頂いております。
WIN 10
FM cloud
FM20
とある仕事の項目をLISTした結果が
日本のエリアで下記のような結果が1フィールドに改行で返されます。
九州
九州
関東
九州
九州
九州
関西
関西
九州
九州
このLISTを
九州：7 関東：1 関西：2
と表記させることは可能でしょうか？
よろしくお願いします。
とても参考になる記事をありがとうございました！！
極力少なくなるように調整したいと思います！
[ Generated in 0.009 seconds, 7 queries executed - Memory usage: 707.13 KiB (Peak: 744.55 KiB) ]