みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
その時に、フラグをたてるための date_genkakakutei という日付フィールドに、Onobjectenter のスクリプトトリガで、
If(Get(アカウントアクセス権セット名) = "eigyo" and IsEmpty ( constraction::date_genkakakutei ) = 0)
カスタムダイアログ表示（"あなたの権限ではこのフィールドは変更できません。"）
フィールドへ移動[]
全スクリプト終了
else
フィールドへ移動[date_genkakakutei ]
end ifとしたのですが、設定してあったドロップダウンカレンダーが開かない状態で停止します。
elseの記述が悪さをしているように思われます。
else
フィールドへ移動[date_genkakakutei ]
ここに分岐した場合、onObjectEnterでスクリプトが再発火してしまうので、無限ループになってしまうのだと思います。
else以下の記述を削除すれば特別な動作はしなくなりますので、目的の動作が達成出来ると思います。
対象レコードの絞込やリレーションを利用した方法が一般的かと思われます。
ブランコ wrote:リレーションは
Aファイル
日付
Ⅱ
Bファイル
日付① ＆ ”...” & 日付②なっています。
宜しくお願い致します。
リレーション 間違えていました。
スクリプトの中になります。宜しくお願い致します。
ちょっとよく意味がわかりませんが
日付①と②を合成したフィールドがあるということでしょうか？
リレーションにしろスクリプトにしろ、イコールで結ぶのなら、Aファイルの日付が「1/15」ならBファイルも「1/15」でなければ成立しません。期間で判定したいのなら、フィールド形式を「日付」にして不等号を使用して複数条件にしなければいけません。>期間で判定したいのなら、フィールド形式を「日付」にして不等号を使用して複数条件にしなければいけません。
教えてください。お願い致します。
結局なにをなさりたいのですか？それがわからないので教えようがありません。あと、ファイルメーカーに関する知識やスキルはどのくらいありますか？
リレーションは
Aファイル
日付
Ⅱ
Bファイル
日付① ＆ ”...” & 日付②なっています。
宜しくお願い致します。
リレーション 間違えていました。
スクリプトの中になります。宜しくお願い致します。
ちょっとよく意味がわかりませんが
日付①と②を合成したフィールドがあるということでしょうか？
リレーションにしろスクリプトにしろ、イコールで結ぶのなら、Aファイルの日付が「1/15」ならBファイルも「1/15」でなければ成立しません。期間で判定したいのなら、フィールド形式を「日付」にして不等号を使用して複数条件にしなければいけません。
社員番号はイコールで結ばれているのはわかりますが、日付をどのような形でリレーションしたいのでしょうか？
見積書に記載された順=レコードが作成された順と見做せるらなば
日付
でソートしてあげれば目的の順に並びます。
計算式で無理矢理順位付けするのは現実的ではありません。
サーバ運用でしょうか？サーバにホストされているグローバル格納はデータが保存されない仕様となっているので、ファイルを閉じた時点でグローバルフィールドの内容は、サーバにアップロードされた時点の値に戻されてしまいます。ローカルファイルだと少し挙動が違いますが。
どのレコードからでも標示できるオブジェクトフィールドを作るなら、専用のテーブルに1レコードだけ作成し、デカルト積でリレーションする方法が考えられます。
あと、オブジェクトフィールドの参照保存は廃止予定の機能です。絶対にバージョンアップしないなら問題無いかもしれませんが、外部保存に切り替えることをオススメします。ＦＭP12はwin10の動作保証外ですし、あまり好ましくない運用に思われます。
繰り返しフィールド[1-2]まで表示するオブジェクトと繰り返し[3]のみを標示するオブジェクトをそれぞれ作成し、[3]のオブジェクトを印刷時非表示設定にすれば可能です。
レイアウト1とレイアウト2は同じテーブル（オカレンス）ですよね。
これの関係を携帯電話の電話帳に例えて説明してみます。
レイアウト1（連絡先一覧）
田中一郎
田中次郎
田中太郎
谷田三郎
レイアウト2（連絡先詳細）
田中太郎
03-xxx-xxx
090-xxx-xxx
tanaka@xxx.com
だとします。レイアウト1の田中太郎を選択すればレイアウト2で田中太郎さんの詳細データが表示されますよね。このときの氏名である田中太郎はレイアウト1と2で同じものなので、2つのレイアウト上の氏名は区別できないし、区別されるとデータベースが破綻してしまいます。
リレーションシップグラフのアーム？をダブルクリックをクリックするとリレーションの照合画面が開きますよね。そのとき、画面下に「このリレーションを利用して、このテーブルでのレコード作成を許可」みたいなオプションがあると思います。
これを有効にしていれば、照合先に対象レコードが無い状態で照合先のフィールドに何かデータを入力しようとすると自動で照合条件に合ったレコードを作成してくれるようになります。
私がよく行う手法は、トリガ用のフィールドを作り、新規レコード作成（リレーション利用）が必要になったタイミングで適当な値（ex:1）を入力するようにしています。
なので、マスタの日付フィールドのスクリプトトリガ（OnObjectExitなど）に日付テーブル？のトリガフィールドに１などを入力するスクリプトを仕込んでおけば、対象レコードの有無の検証を行う工程は省くことが出来ます。
もう解決済みのようですが、同じ落とし穴にはまったことのある人間の意見が参考になれば。
ユーティリティテーブルの1レコード運用の何が問題かといいますと、１つのレコードでは同時に複数人が編集する場合、たとえグローバルフィールドによるリレーションであっても（リレーションの照合先が別であっても）
検証元（ユーティリティテーブルのレコード）が同一であるためロックがかかるわけです。
これの回避方法としては
①ログイン時にユーティリティテーブルにレコードを作成、ファイルを閉じる際に当該レコードの削除
②ユーザ分だけレコード作成し、どのレコードをどのユーザが使用するか決める枠組みを作り、ログイン時に検索等で振り分ける。
が考えられます。上記の二つはどちらも一長一短です。
この方法を利用すればPiroさんが元々使用していたスキーマを変更することなく複数人での編集が可能になるはずです。
色々な手法があって面白いですね。私はさすらいのダンサーさんと同じで、透明ボタンでtab順の最初と最後のフィールドにスクリプトトリガでkick outするようにしてました。
普段ほとんどオブジェクトフィールドを使用しないので、透明ボタンの弱点を知れて良かったです。
透明ボタンを使用する前は別レイアウト（原本）でスライドコントロール上にレイアウトを作成、フィールド入力の制御を変更して複数コピペ、オブジェクトを隠すで表示するスライドを決めるという手法をとっていました。
この手法は原本で修正する事を忘れると少しめんどくさいことになるので止めました。
フィールド毎にスクリプトトリガで制御する手法は、新規フィールドを追加する際に既存のフィールドをコピペして使用すればほとんど手間はかからないし、良い手法だと思いますが。
計算フィールドで常に"未稼働"と評価されるフィールドを作成します。このフィールドと「稼働中」か「未稼働」の入るフィールドとリレーションを組みます。
あとはリレーション先の空白禁止フィールド（ex:主キー）をカウントしてあげればいいです。
Aテーブルの集計用フィールドが、集計フィールドや非保存計算フィールドでないのならぱ、それがパフォーマンスに影響するとは考えにくいです。疑うべきはリレーションでしょう。リレーションを外しても直ちに影響がないなら、一度リレーションを外して動作確認をしてみて下さい。それで改善するならば、リレーション先のデータやリレーションの設定に問題があります。
シンプルなファイル構成ですし、わざわざ分離モデルにするメリットは無いと思われます。
分離モデルの最大の特徴は、I/Fとデータ格納ファイルの分離です。そこまで作り込むのはソリューションの構造を大きく変える必要があります。単純に現在のファイル+集計用ファイルにするだけなら、管理の手間が増えるほぼデメリットしかない分離だと思います。
自己連結リレーションテーブルに元テーブルの集計フィールドを配置すると似たような動作になるので、そういったことがないかの確認のためです。
と思ったんですが、ちょっと動作を勘違いしていたかもしれません。基本情報テーブルに関連レコード先の合計okを計算させることが目的でしょうか？
リスト一覧レイアウトのテーブルは何になってますか？
自己連結リレーション先のテーブルになってたりしませんか?
前回の値はどのように利用されるのですか？ただレポートに表示させたり、比較用に利用するならデータのルックアップではなく自己連結テーブル先のフィールドを利用したり、関連レコードへ移動を利用した方がよいです。
ですよね。
最初に習った人（プロではないです）に、そう教わったため、なんとなく惰性で付けていました。
これからは＃等を付けるようにします。
使用したのはlet関数と云いまして、これを使用すると計算式の前に変数を宣言することが出来るんです。
式内で繰り返し使われる値や、計算結果等を変数に代入してやることで記述をシンプルにすることを目的として使用しています。
$TDY←ここに今月（今なら8月）
を代入しています。$マークは不要ですが、私はなんとなく入れています。
私の場合、能力不足のためcase関数で場合分けをしていますが、shinさんのように普遍的な式に落とし込む方がよりエレガントだと思います。（個人的感想）
あと、出来れば式のベタ移植ではなく、どういう意図で式が書かれているかを理解しながら使用すると、ご自身の力になるのでオススメですよ。
すみません。誕生日の半年後以降を考慮してませんでした。
Let
(
[
$TDY = Month ( Get ( 日付 ) ) ;
$BTD = Month ( 生年月日 ) ;
$DST = Case ( $BTD - $TDY ≥ 6 ; -6 ; $TDY - $BTD > 6 ; 12 ; $TDY > $BTD ; 6 ; 0 )
]
;
Date ( Month ( 生年月日 ) + $DST ; 1 ; Year ( Get ( 日付 ) ) )
)こちらでどうでしょう。
こんなのはいかがでしょう？
非保存計算フィールド：日付形式
Let
(
[
$TDY = Month ( Get ( 日付 ) ) ;
$BTD = Month ( 生年月日 ) ;
$DST = Case ( $BTD - $TDY ≥ 6 ; -6 ; $TDY > $BTD ; 6 ; 0 )
]
;
Date ( Month ( 生年月日 ) + $DST ; 1 ; Year ( Get ( 日付 ) ) )
)この場合、生年月日から半年後のフィールドは不要になります。
『スクリプト の基礎の基礎』という動画で語られてた「手作業の順序でスクリプトを書く」ことでやっとスクリプト が動くのを実現できたような段階なので、二次元的にということも含め思いつかないことがまだまだたくさんです。。
この動画を見たことがないのでよくわからないですが、自分の実現させたい事を手作業で行い、その動きをスクリプトに書き出すといったようなものでしょうか？
この考えをもとにスクリプトを見ると、やりたい事としては対象レコード全ての色番号フィールドに色を設定するわけですよね。そのためには、ループで五月雨式に色を入力する前に、アクティブレコードを最初のレコードにしてやる必要があります。
つまり、ループスクリプトのすぐ手間にレコード移動:最初をループスクリプトの「次のレコードに」とは「別で」配置してやる必要があります。
ファイルメーカーに限らず、ループ処理というのはループのすぐ手前に初期値を宣言してあげるのが一般的なスタイルです。
二行に近づけられる様に勉強していきたいと思います。（今は90行くらいです笑）
二行といったのはインポートの核となる部分の話で、対象レコードの指定やらを含めると二行では難しいです笑。
しかし、90行ですか。私は頭の出来があまりよろしくないので、90行のスクリプトステップを読むのは脳が拒否しそうです。やはり繰り返し計算フィールドのマスターをオススメします。
shinさん
サンプルファイルありがとうございます。
ポータルを複数行にして横に７つ配置しても get(計算式ポータル行番号)的な関数が無いから、今の方法以外では無理だと思ってました。
まさかList形式でカレンダー表示をするなんて発想はありませんでした。これなら作成時の大幅な時間短縮が可能になりそうです。ご教示ありがとうございます。
（3.で検索しているので最後まで行くと次のレコードはないのは当然なのですが。）
これを回避するにはどうしたら良いでしょうか
ループの前にレコード移動:最初を置けばいいのでは？
インポートオプションの繰り返しフィールドをレコード分割は非常に役に立つので覚えた方がいいテクニックです。
質問者さんのフィールド構成がよくわからないのでなんとも言えませんが、少なくともカラーバリエーション情報を保持した商品詳細レコードの作成はスクリプトを一箇所変更するだけで作成可能です。
shinさんのサンプルファイルを見たわけではありませんが、カラーバリエーションとサイズを二次元的に繰り返し計算フィールドに落とし込む式は、ヘルプとにらめっこしながら読んでいけば充分理解出来るものだと思います。これが理解出来れば質問者さんの目的とするスクリプトは
レイアウト切り替え
インポート
のわずか二行で実現可能です。
[ Generated in 0.010 seconds, 9 queries executed - Memory usage: 720.77 KiB (Peak: 758.55 KiB) ]