みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
いつも勉強させていただいています。
早速ですが、質問です。
まずは当方の環境から
ＯＳ：Ｗｉｎ7
ＦＭ：ＦＭ11Ｐｒｏ
です。
開発状況としましては、
ファイルＡ
ＩＤ テキスト
開始日 グローバル
曜日 計算[7] 非保存,from ファイルＡ,=Choose(Get(計算式繰り返し位置番号);"";TextColor("日";RGB(255;0;0));"月";"火";"水";"木";"金";TextColor("土";RGB(0;0;255)))
日付 計算[42] 非保存,from ファイルＡ,=Let([$start=Date(Month(開始日[1]);1;Year(開始日[1]));$date=$start + Get(計算式繰り返し位置番号) - DayOfWeek($start)];$date)
注文 テキスト[42] ルックアップ
ファイルＢ
ＩＤ テキスト
注文日 日付
注文 テキスト
というファイル構成で開発しています。他にもフィールドはあるんですが最小構成で質問いたします。
もうわかっている方もいると思いますが、これを使って日々の注文状況の記録を取っています。
リレーションは、ファイルＡ::ＩＤとファイルＢ::ＩＤ、ファイルＡ::日付とファイルＢ::注文日で行っています。
画面は、一般社員用の入力画面と管理者用の画面があって
一般社員用も管理者用も7×６のカレンダー状に入力項目を配置しています。
ただ、一般社員用の方は入力画面に入る前にＩＤを入力させて社員一人分の情報しか見れないようにしています。
一方、管理者用は全社員の情報を見れるようにカレンダー状のリスト形式で表示させています。
で、悩んでいるところはこの状態で日付を送った時にかなり時間がかかってしまうというところです。
画面上に『前月』『当月』『次月』というボタンを配置しスクリプトパラメータにそれぞれ『-1』『0』『+1』を
設定して
スクリプト：
If[Get ( スクリプト引数 ) = 0]
フィールド設定[フィールドＡ::開始日;Date ( Month ( Get ( 日付 ) ) ; 1 ; Year ( Get ( 日付 ) ) )]
Else
フィールド設定[フィールドＡ::開始日;Date ( Month ( 弁当予約ﾃｰﾌﾞﾙ::開始日 ) + Get ( スクリプト引数 ) ; 1 ; Year ( 弁当予約ﾃｰﾌﾞﾙ::開始日 ) )]
End If
フィールド内容の再ルックアップ[ダイアログなし;ファイルＡ::ＩＤ]
というスクリプトを実行するようにしています。
この時、一般社員用の画面では更新にさほどストレスなく切り替わるんですが
管理者用の画面での更新時間がちょっと長いです。だいたい４０秒くらいかかります。
ファイルＡの中には約60件、ファイルＢには約７００件ほどが入っています。
システムはファイルメーカーサーバー上にあって30キロほど離れた場所からアクセスします。
原因はサーバー上にシステムファイルがあるからだと思います。
現にローカルで同じように組むと全くストレスなく動作しますので。
ローカルでのテストが成功したのでいざサーバーの本システムに組み込んでテストしたところ
管理者画面での更新時間がかかるようになってしまいました。
正直、日付を1か月送るだけで40秒もかかってしまっては使えるシステムとは言えません。
なので高速化する方法がなにかないかと思いこちらに投稿させていただきました。
フィールド内容の全置換とかも使用してみたんですがなかなかうまくいかなくて・・・
どなたかご教授いただけると大変助かります。よろしくお願いします。
ちなみに、ファイルＡの注文を計算に変更することはできません。
カレンダー上での入力が今回の開発のキモになっているので。
乱文・長文で申し訳ありませんがよろしくお願いします。
ローカルで、他のPCでそのファイルを開き共有させ、他の端末から共有させたファイルを開いて同様の作業ではどうなりますか。それで十分な速度が得られるなら、回線の速度の問題でしょう。
大量のルックアップ（60×42）がかかっていますので、かなり重たい処理になると思います。
ルックアップ関数を使って再ルックアップをしないで済むようにするか、カレンダー形式での表示をあきらめて、1日1レコードのリスト形式にするのが簡単かと思います。
ところで、テーブルAで入力されるように思えるのですが、そのデータはどのようにテーブルBに反映させているのですか。
Last edited by Shin (2016-04-09 14:43:11)
Offline
Shin様、返信ありがとうございます。
ローカルで、他のPCでそのファイルを開き共有させ、他の端末から共有させたファイルを開いて同様の作業ではどうなりますか。それで十分な速度が得られるなら、回線の速度の問題でしょう。
大量のルックアップ（60×42）がかかっていますので、かなり重たい処理になると思います。
ルックアップ関数を使って再ルックアップをしないで済むようにするか、カレンダー形式での表示をあきらめて、1日1レコードのリスト形式にするのが簡単かと思います。ところで、テーブルAで入力されるように思えるのですが、そのデータはどのようにテーブルBに反映させているのですか。
そうですね。考えてみれば60×42のデータの再ルックアップですから時間がかかって当然ですね。
検証はしていませんが、回線の問題の可能性が大ですね。
ただ、カレンダー形式以外での入力は変更できません。実はすでにＶｅｒ１がリリース直後なので。
Ｖｅｒ１では、ファイルＢにも注文内容を保存してファイルＡの注文フィールドにも内容を保存する方法で対処していました。
当方では2か月分のデータを持つようにしているのでこの方法だと、ファイルＡに1社員2レコード×60とファイルＢに
1社員1日1レコード×2か月分のデータ×６０となっています。
ファイルＢのデータ量は変わらないんですが、ファイルＡに2か月分のデータを持つのがなんだか効率が悪く感じたのと
月を移動するときにいちいち検索をかけて月表示を切り替えているのも効率が悪く感じたので
こちらで紹介されていた予定表などのサンプルをもとに、ファイルＡには1社員1レコードだけを持って『開始日』フィールドを変更するだけで
日付データを生成するように変更したほうが効率がいいと思ったので改造し始めたんですが再ルックアップで時間がかかってしまったわけです。
ちなみに、ファイルＢにデータを書き込む方法はこれもこちらで公開されていたサンプルを参考に
まず、ファイルＡに
Key日付 日付 グローバル
を作成して、ファイルA：：Key日付とファイルB日付、ファイルA：：IDとファイルB：：IDでリレーションを作成します。
次に、ファイルＡの[注文]フィールドの『ＯｎＯｂｊｅｃｔＥｎｔｅｒ』に
変数を設定[$$日付；値：GetRepetition ( ファイルＡ::日付 ; Get ( アクティブ繰り返し位置番号 ) )]
変数を設定[$$注文；値：GetRepetition ( ファイルＡ::注文 ; Get ( アクティブ繰り返し位置番号 ) )]
変数を設定[$$ＩＤ；値：ファイルＡ::ＩＤ]
フィールド設定[ファイルＡ::Key日付；ファイルA::日付[Get(アクティブ繰り返し位置番号)]]
というスクリプトを設定します。
さらに、ファイルＡの[注文]フィールドの『ＯｎＯｂｊｅｃｔＳａｖｅ』に
変数を設定[$$最新注文；値：GetRepetition ( ファイルＡ::注文 ; Get ( アクティブ繰り返し位置番号 ) )]
Ｉｆ[IsEmpty ( $$注文 ) and not IsEmpty ( $$最新注文 )]
レイアウト切り替え[｢ファイルＢ｣(ファイルＢ)]
新規レコード/検索条件
フィールド設定[ファイルＢ：：ＩＤ；$$ＩＤ]
フィールド設定[ファイルＢ：：日付；$$日付]
フィールド設定[ファイルＢ：：注文；$$最新注文]
Ｅｎｄ Ｉｆ
Ｉｆ[IsEmpty ( $$最新注文 ) and Count ( ファイルＢ::ID)]
関連レコードへ移動[関連レコードだけを表示；テーブル：｢ファイルＢ｣；使用するレイアウト｢ファイルＢ｣(ファイルＢ)]
レコード/検索条件削除[ダイアログなし]
Ｅｌｓｅ
関連レコードへ移動[関連レコードだけを表示；テーブル：｢ファイルＢ｣；使用するレイアウト｢ファイルＢ｣(ファイルＢ)]
フィールド設定[ファイルＢ：：注文；$$最新注文]
Ｅｎｄ Ｉｆ
レイアウト切り替え[｢ファイルＡ｣(ファイルＡ)]
というスクリプトを設定してファイルＢにデータを書き込んでいます。
なんとか、カレンダー表示を維持しながら再ルックアップをしないでフィールド内容の更新をする方法がないでしょうか。
一応、試した方法は、
フィールドＡの[注文]フィールドを
注文 テキスト[42] 計算値自動入力 既存値置き換え(内容は[= 注文2])
と変更して
注文2 計算[42] 非保存、from ファイルB、＝LookUｐ(ファイルB::注文_変換;"")
として、ファイルBに
注文_変換 計算[42] 非保存、from ファイルB、＝注文[1]
としてやってみたんですが、ファイルAの[注文２]まではデータが引っ張れたんですが
そこから[注文]に反映ができませんでした。
ここがうまくいけばいいのですが・・・。
いろいろと試行錯誤しているのですが、なかなかうまくいきません。
乱文・長文で申し訳ありません。
さらにご教授いただけると幸いです。よろしくお願いします。
全体が見えないので、何とも。以前の弁当の注文の続きですか。
Offline
Shin様、返信ありがとうございます。
全体が見えないので、何とも。以前の弁当の注文の続きですか。
覚えていただいていましたか。ありがとうございます。
そうなんです。あの弁当のシステムなんです。
当方では、3か所に就業場所があって当初はそのうちの1か所でのみこのシステムを
導入するはずだったんですが、概ねこのシステムの評価が高く全社的に広げていく
ことになり、いろいろと調整をしていくうえで修正をしようと思って
改造に着手をしてこの問題に気付いた次第です。
以前に、Shin様にいただいたサンプルは非常に素晴らしいのですが
あの時の時点で、すでにカレンダー用と日別データ用2ファイルで管理する方法になっていたため
改造箇所が多く採用を断念しました。申し訳ありません。
何か良い方法があればいいのですが。
その構造では、根本的な部分でデータの転送が非常に多く、遅い外部回線を通した共有は無理だと思いますが。
Offline
全体が見えていませんのでトンチンカンでしたら御容赦を、、
テーブルAは1社員ごとに1レコードで固定しているのですよね。
それを
1社員&ひと月
ごとに1レコードとしたらいかがでしょう。
これなら、
月の前後の移動はレコード移動だけですよね。
Offline
Shin様、返信ありがとうございます。
その構造では、根本的な部分でデータの転送が非常に多く、遅い外部回線を通した共有は無理だと思いますが。
そうですか・・・。
やはり無理なのですね。根本的に構造を変えるか、今のままで別の方法を考えるかですね。
一つわからないのは、私が試した方法でなぜ値が反映されなかったかということです。
2回目の投稿で
ファイルＡを
ＩＤ テキスト
開始日 グローバル
曜日 計算[7] 非保存,from ファイルＡ,=Choose(Get(計算式繰り返し位置番号);"";TextColor("日";RGB(255;0;0));"月";"火";"水";"木";"金";TextColor("土";RGB(0;0;255)))
日付 計算[42] 非保存,from ファイルＡ,=Let([$start=Date(Month(開始日[1]);1;Year(開始日[1]));$date=$start + Get(計算式繰り返し位置番号) - DayOfWeek($start)];$date)
注文 テキスト[42] = 注文2
注文2 計算[42] 非保存、from ファイルB、＝LookUｐ(ファイルB::注文_変換;"")
として、ファイルＢを
ＩＤ テキスト
注文日 日付
注文 テキスト
注文_変換 計算[42] 非保存、from ファイルB、＝注文[1]
として実行したとき
ファイルＡの注文２まではデータの反映に成功したのに注文２を注文に反映することができませんでした。
ここがうまくいけば良いのですが、うまくいかない原因がわかりません。
やはり再ルックアップをかけないといけないってことなんでしょうか。
チポ様、返信ありがとうございます。
全体が見えていませんのでトンチンカンでしたら御容赦を、、
テーブルAは1社員ごとに1レコードで固定しているのですよね。
それを
1社員&ひと月
ごとに1レコードとしたらいかがでしょう。
これなら、
月の前後の移動はレコード移動だけですよね。
すいません。私の説明が拙いせいで混乱させてしまったようで。
一応、Ｖｅｒ１のデータ構成は1社員1月1レコードで持っています。
例えば、今だとＡという社員のデータは4月分と5月分の2か月持っている形に
なります。
ただこれだとなんだか効率が悪いように思ったので
ファイルＡのデータは1社員1レコードで開始日を変更するだけで日付の数値を
変更するようにすれば効率がいいかもと思って改造し始めたら
再ルックアップにかなりの時間がかかることが判明したということになります。
う～んなんだか、うまく説明できない。
やはり今の状態で改造をしていくしかないようです。
> ただこれだとなんだか効率が悪いように思ったので
>
> やはり今の状態で改造をしていくしかないようです
なぜ効率が悪いのですか？
現状に問題があるのですから、他の方法を考えるのも一つの手では。
再ルックアップをしない方法を模索すべきでしょう。。
Offline
チポ様、返信ありがとうございます。
> ただこれだとなんだか効率が悪いように思ったので
>
> やはり今の状態で改造をしていくしかないようです
なぜ効率が悪いのですか？
現状に問題があるのですから、他の方法を考えるのも一つの手では。再ルックアップをしない方法を模索すべきでしょう。。
参考にした、ＴｏＤｏリストのシステムなどを見るとカレンダーをコントロールするテーブルでは
1社員1レコードにして、ＴｏＤｏの内容を別テーブルで管理するというサンプルが
ほとんどでした。
そうすることにより、レコードの移動や集計などが簡単になると思ったのと
テーブルＡでカレンダーを管理して基準日を移動するだけでテーブルＢの内容が反映される。
なんて感じで組めればなんだかかっこいいかなと思ったのがきっかけでした。
ただ、その時はローカルでのテストに成功していた段階でしたのでまさかサーバに上げた途端
こんなに時間がかかってしまうようになるとは思っていなかったので。
とりあえず、Ｖｅｒ1がリリース直前なのでそれをベースに修正と改造を行っていこうと
思います。
いろいろとご助言ありがとうございました。
Pages: 1
[ Generated in 0.008 seconds, 9 queries executed - Memory usage: 565.31 KiB (Peak: 585.85 KiB) ]