ファイルメーカーユーザの集い Part5
■ このスレッドは過去ログ倉庫に格納されています
前スレ
ファイルメーカーユーザの集い Part4
http://mevius.5ch.net/test/read.cgi/bsoft/1504481812/
◆メーカーサイト
http://www.filemaker.co.jp/
◆定番サイト（国内）
FMJML
http://filemaker-ml.jp/
★初心者のFileMaker pro Q&A★
http://joy-h.com/bbs2/index.php
FMPro.jp
ttp://www.fmpro.jp/
Knockin' on Seven's Door
ttp://www.sevensdoor.com/
FAMLog
ttp://www.famlog.jp/
◆定番サイト（海外）
ISO FileMaker Magazine（Tips、動画解説）
http://www.filemakermagazine.com/
BrianDunning.com（カスタム関数）
http://www.briandunning.com/
Database Pros（Tips）
http://www.databasepros.com/
質問・相談は環境・バージョンを忘れずに。テンプレ以上。 >>767
これとこれを足し引きしたいってときにもちょっとじゃないからね データベースはデータ入れとくだけのものだし
本来はそのデータをエクスポートしてレポートなり計算なりやれってものだったはず
ファイルメーカーなんかはレポートも割とこったのできちゃうから
逆にそのせいでファイルメーカーだけで完結させようとしてむずかしくなるんだよね でもね、データの格納とインターフェイスを変えたとしても
例えば、初期のFMみたいにカード型だったとするじゃない？
そのカードをめくるっていうようなのがエクセルだと至難
ネットワーク共有するもリアルタイムの更新もできない
元は同じでも、別物かと思う ファイルメーカーサーバーとプロの構成です
放置してるときに、再描画させるような動きが発生して
凄く重いです
後は、色んな人が同時実行するとやたら重くなります
ファイルメーカーって、一体何してんでしょう
ヘルスチェックはしてるようなんですが
SSDにしたら速くなるのか
ネットワークの帯域が狹すぎて重くなるのか
はたまたロックでも掛かっているのか
サッパリ解らず
先輩方のお力を貸していただきたく 普段オフラインのipadをオンラインのときに手動で同期するのってどうしてますか？
PCとipadで変わったらところだけを更新したいです 一月あたり
2150円もするのか
しかも5ユーザーから
パッケージふたつかってもテスト以外の共有は規約違反らしいひ
小規模オフィスは完全に相手にしないスタイルに切り替えたのか >>771
どのような使い方？、重い画像を扱っている？
テキスト中心であればクラッシュではないか ああそうか
計算のフィールドが引っ張って演算しまくりか
設計が悪いな
重いレイアウトでフィールド一個ずつ蓮して
検証すればいい やたらと集計フィールドを貼り付けてたり
非保存の計算フィールドが同上だったり
画面のオブジェクトを隠す計算式が同上だったり Sumを計算フイールドで使うと遅くなるで
数値フィールドにしてスクリプトでSumの値を貼り付けると爆速やで ちなみに、FMだけに限らない
どのDBだろうが言語だろうが同じ >>780
対象フィールドの更新のたびに計算する仕組みにするってこと？
前からそっちのほうがすっきりするに管理もしやすいと思ってたけど速度的なメリットもあったんだね
Excelにしろ絶対数値で貼り付けたほうがいいと思ってたよ これはwebの設計でも同じで
一つのページを表示させるのに、たくさんファイルを開いて
処理したりしていたらサーバの負担も大きいし遅くなる。
今はサーバもssdになってきて早くなっているとしてもね。
だから更新時に処理して静的なデータとして保管。
画像も同じ。サムネイルなり、アイコン化して見せないと
クライアントからいっぱい表示していたら重くて当然だし。 なんなら計算フィールドなんていらなきレベルとまで思えるよね
請求書の単価×個数
までスクリプトでやってる
フォームちまちまやるより
一括で変更できるし楽 例えば勤怠管理なんかで
年間の累計労働時間のSUM
それから累計休憩引く計算フィールドと
さらに月ごとの上限設定してオーバーしてないかのチェックをする計算フィールドがあるとすると
どういう具合にスクリプト組むの？
表形式のときですらスクロールしたらガクガクでびっくりした SUMが多数あって、それを利用するフィールドが多数連なってると、難度増すで
勤怠で勤務時間を変更すると多くの処理に影響するやろし、さらに日/週/月/年毎の労働時間や金額の計もスクリプトで更新しようとすると熟練業者でもえらい面倒やで
この話はFMに限らんけど、FMはマトモなトランザクションがないので長い処理が途中で失敗してもロールバックできないのが癌や
業者に改修依頼しても、ごっつうカネかかるやろな 速度の違いは計算式かどうかよりも非保存か保存かだよ。
非保存になってしまう計算フィールドだと遅い。なによりインデックスも作れないから
リレーションも取れない。非保存フィールドは可能なら作らないが吉。
表示だけのものならレイアウト上にボタン作って計算させるとか色々あるけど面倒だよね。
FMにはviewが無いってのもレイアウトのためだけの計算式が増殖する原因だから
オカレンスの仕組みを変えてview用のフィールドをオカレンス単位で作れるようにならないかなぁ。 ただ、サーバが重くなるのと、クライアントが重いのは
少し違うと思う。FMの場合はとくに。
通常の計算式でクライアントが重いのはデータ引っ張りながら
クライアントで演算するからなんで。 >>786
どうやったらいいんですかね？
自己リレーション貼りまくってSUMしまくってるけど先述のようにスクロールすらおもいです 例で言うと、例えば日計表とかに顧客の取引の回数を
表示させるするとする。
もしこれを日経表で１回１回演算させていたら重いので、取引の
入力時に計算してフィールドに「回数」をスクリプトで入れる。
これを日計で表示させる、とかそういうこと。
顧客の年齢なども同じ。
また、FMには癖があって、リレーションで引っ張るもの
と引っ張られるものとは処理速度が違う。
例えば負担大の maxやminでリレーション値を比較する
なんてものがあったら重いので、複数させない。 なんでセルフが出てくんのかわからんわ
FMで日毎社員毎に時間計を持たすなら日付tbl作って日付/社員id/時間計を入れる
週、月でも同様にテーブルとフィールド作るんやで
それやったらリレートできるやろ？
時間計を計算でSUMするかスクリプトなんかは難しいとこや
ただ社員がウン十人以上規模のシステムなら悪いことは言わん、業者に頼んだほうがええで 日/週/月/年毎の労働時間をやるのはスクリプトでも重いってことなんですか？
というか集計に関しては常に全レコードが対象になってしまいますよね（あとから修正したときにもスクリプト回さないといけないし）
スクリプトで出した集計結果は対象のすべての集計結果フィールドにもいれなきゃいけませんよね
Excelにだしてそっちで計算するとかしかないのかな
こんな具合に時間の集計もしたいんですよね
https://i.imgur.com/7eQVNP5.jpg 日/週/月/年毎の労働時間は
日の労働時間 → 週労働時間
+→ 月労働時間 → 年労働時間
の関係性で、かつ更新タイミングは通常前日の締め時間以降に1回だけで良いのだから
サーバサイドスクリプトで夜間のバッチ処理にしておけばいいんでないの?
まあ、現実には後から数日前の時間修正とか発生することがあるから、そのときは
日付を指定して手動で回すとか工夫は必要だけど。
少なくともそれで表示の度に時間がかかるって事はなくなるだろう。 Sumはスクリプトでも計算フィールドでも速度はそな変わらん思うわ
だだスクリプトSumは一回数値フィールドに保存すれば後から集計する時爆速や
スクリプトSumした値が変更されると、当然ながらその値を参照しているフィールド値は全て更新要や
スクリプトで更新するなら786のように大変やで
Excelデー言うても、勤務時間変更するたびに書き出しやらクエリかけてたら、FM単独の方がよほど早くて簡単や思うで >というか集計に関しては常に全レコードが対象になってしまいますよね（あとから修正したときにもスクリプト回さないといけないし）
普通、更新したかどうかはフラグかなんかで持たせておいて、集計したら落とす、修正したら立てるとか
やっておけば最初にフラグが立っている人の日付分と関連する週、月、年の集計だけ計算すればいい。
フラグを立てたり落としたりはレイアウトのスクリプトトリガでもいいし、フィールドの自動計算でやらせてもいい。 あとその社員月集計画面な、ヘッダ部は社員毎/月毎の集計やんか
ボデェ部は社員毎/日毎で勤務明細tblをSUM等してるように見える
てことは、1社員×30日×明細10×計算フィールド10とすると、OnRecLoadで計算対象となるフィールド計は3000位やろ
これで速度ガー言うオバハンがいるなら、日テーブルの数値フィールドに保存するよう仕様変えれば300になって、10倍早くなるんちやうか 19で作成したやつを17にいれてランタイム版作ることって不可能ですか？
できるなら中古で買おうと思います 計算フィールドはスクリプトトリががなかった頃は便利だった。トリガが実装されてからはスクリプトで計算する方が圧倒的にパフォーマンスが良い >>799
18 19で追加された機能は使えないけど、形式は同じなんでOK。 おいおい、結局無料でリリースするって話は無くなったの？
とんでもないフェイクニュースだったな。 顧客データのテーブル、1取引ごとのテーブル、日計などのテーブルがある
1. 取引の残金が発生した場合は、どうやって扱えばいい？
2. 1月に特定の金額、例えば5000円越えたら何割引とか
するための、月ごとの金額の合計はどうしたらいい？
どうもレコードを繰り越しての処理が苦手で、逃げてきたが
なんとかしたい。 Proの無償化、まだ決まってないんちゃうか
はよハッキリして欲しいわ
詳しい人、頼むで >>805
合計請求書のテーブルを作って得意先コード、請求年月で前回繰越額、今回買上額と値引額を管理
今それぞれの取引を管理しているレコードに請求したときの合計請求書を紐付ける=まだ紐付いていないレコードは未請求だとわかる
みたいな感じでできない？ >>806
ブログのやつしかいってない情報だからな
虚言癖なんじゃないか？ >>807
なるほど、月ごとの集計のテーブルね
やってみる >>776
まさか反応があるとは、思わず
まずはお礼をさせてください
画像とかは使ってません
ただ、フィールドは多いですし、計算もしてます
サーバーの処理中が増えると遅くなるんですよね
処理中が少ないと、まんざらでもない
故に、通信の設定周りが怪しいのかなと
調べていました 続きです
使っている人は100人も居ません
実行中が5辺りから、激重モードになります 計算に使っているテーブルで
数百万レコードの情報があり
試しに、その計算を消してみたが
実行中のタスクが増えると激重化します それと、サーバーの電源プランや
データロックや、裏でバシバシと
データ更新されたときの
スローダウンがあるのかなと
oracleやら、sqlserverみたいなトレースツールが少なくて
マジできついです > 使っている人は100人も居ません
> 実行中が5辺りから、激重モードになります
テーブル設計が怪しい思うわ
Sumやら集計の計算フィールドがレイアウトにあって、表示される度に数千件対象の計算走るとか
あと、やったら長くて重たいスクリプト走ったりすることもあるな
デバッガでちゃんとチェックしてまっか？
ウン十ユーザがぶら下がるんならマトモな業者に頼んだ方がええで
FMはお気楽に導入できるんやが数百万超えるテーブルやウン十ユーザ〜のシステムになると相当な経験値要るで ありがとう御座います
sumは、わからんですが計算はワンサカしてます
※非保存と、保存の違いはわかっていない
ただ、その辺のフィールドーの参照をレイアウトから取っ払っても（正確には自分は対応してなくて、詳細不明)、実行中のタスクが増えると
激重なのです
グラブが多い画面なので、その辺も怪しいと思ってますが、わからないです
私はデバッグできるライセンスもらってないんですよ
だから、直感と、リソースモニター、
adminコンソールとか見て
頭を悩ませてます
FileMakerserverとセットだと常に通信してる仕組みが読み取れたので
※差分データの更新的な動きや
クライアントの生存チェックやらしてる模様
直感的に通信が怪しいと感じています
ディスク速度も怪しいですが
ぶっちゃけ一人のデータ表示してるだけの画面なので
業者の方にも頼んでいるのですが
インフラ周りはお手上げのようです
前述の対応してもらいましたが
マルチスレッドに激弱だなという印象 メインテーブルが800位、項目があった記憶があるので
その辺はどうなのかなあと思っています
ただ、今更そこを弄るのは危険すぎるなあと いやもう無茶苦茶だと思うけど。
1から業者に任せて作り直した方がいいレベル。
そもそも表示するだけなら全部計算する必要ないでしょ。
保存しとけば再計算はしないけど、保存しないなら開くたびに計算するからデータ数多いとサーバーにとんでもない負荷かけるよ。
必要なデータを抜き出して、そこから計算でしょそもそも。
設計が腐ってる。
ネットワークとかそういう問題じゃない。 ちょっと前にあったけどスクリプトで計算するってやつ
あれ計算値保存にしててもはやいものなの？
なんなら保存非保存関係なく計算フィールド自体が重いので全部スクリプトとか？ >>818
基本ほとんどの部分スクリプト計算の方がいい。
それでもsumとかで毎回合計を貼り付けるスクリプトだとレコードが膨大になると処理に時間がかかってしまうんで差分計算するといい
OnObjectEnerでフィールドの元の値をグローバル変数に保存する。
↓
OnObjectSaveで変更後のフィールドの値からグローバル変数の元の値を引いた数値を合計フィールドに足し合わせる
この方法だとレコード数が数百万になっても使用してるレコードは２つだけなんで処理が重くならない FMだけで問題発生なら通信ちゃうんやないか
インフラ周りはお手上げ、ってFM業者にLANの設計保守頼んだらあかんで
導入時依頼した業者か専門業者に頼まんと
最近ルータやらハブやらの通信機器いらったなら、それ交換やら元に戻すと治ることあるけどな というか、FileMakerは余程の下手を打たなければそれほどLANの負荷は高くならない。
それよりも計算式やソート、スクリプトトリガを疑ったほうがいい。
特にリレーションのソートの項目が非保存フィールドだったりした日にはもうね…。 設計やけどな、フィールド印刷して、Sumやらcount使った非保存の計算フィールドがぎょうさんあったらそれ怪しいわ
問題のレイアウトからそれらの計算フィールドや関連するグラフを1つずつ除いて、CPUモニタの値がガクっと落ちたらそれが癌やで
話聞いてるとユーザ企業側の担当さんみたいやけど、他のFM業者の話も聞いた方がいいんちゃうんか 皆さんありがとうm(_ _)m
ネットワーク周りが怪しいと感じたのは、
他に同じOSのクラサバサーバー(DBとかキューとかかな？)があって、
設定が弄られてたのです
この辺の情報ですね
https://ameblo.jp/toppi-567/entry-12267299432.html
因みに何れもプライベートネットワーク
また、WEBアプリ(パブリック)を使って、イライラしてる人もいます
それで怪しいなと感じました
その業者に確認しても、ナンスカそのパラメタ？って感じで、確認待ち状態
勿論、計算フィールドも怪しいのですが
一からやり直すのは流石にきついかなと
フィールド消しつつ確認してみます
取り込みバッチを定間隔で動かしてるのも
不味い気がするですが
そのデータを参照して画面表示してたり
他の業者の意見については、確かにそうですね
信用とお金、色々とありますが相談してみます
元々、作るのが専門だったので何かと悩ましいです >>823
ホスト間のスループット計測とかして問題の切り分けが先でしょ >>824
仰るとおりですが、
何すりゃいいかイマイチ
cpu待ちが多ければ、ｉｏが不味いのかなとか ネットワークなら、あるべきスピード出てるか計測するとかですかね？
何のTOOL使えば良いか、からですね
何でも聞いてんじゃないと言われそうですが >>825
ローカルでFMP直接開いて試すとか?それでも遅いなら設計見直し・・・10年以上運用の月次年次売上集計ウチでは気になるほど遅くなってないけどな・・・
ちなみに何んでもスクリプトは反対派かな。スクリプトの見通し悪すぎるし、そこまでするなら.NET + ppstgres/MySQLにするか、いっそ4Dにするか
FMの良さはお手軽自前構築＆共有＆気になったら即修正とオモフ
そういえば言語スクリプト搭載の噂どうなったんだろうね2018頃聞いたけど >>826
ローカルで一人で使う分には、まあまあのレスポンス何ですよね
サーバーが絡んで、実行中のスレッドが溜まると激重なんです
溜まるといっても、5本とか...
色々と試したり、業者の方とタッグを組んで何とかしてみます
保守料払ってんのか謎ですが...
確かに.netとかにした方が良いのかも知れませんね通信しまくりとかないし
以前、vb6からのマイグレでパフォーマンス問題だらけで地獄でしたが
最近のpcなら問題ない筈
しかしＦＭの常に通信する仕様は
やめられないのだろうか...
後勝ち更新じゃ駄目なのか クライアントからソートさせる（リレーションでも）
設計も重くなるな。そこに早くないWifiが挟まると
もう大変。 なんでなのか
例えばWebサーバ上でのスクリプトはサーバで実行
して結果を転送だが、ファイルメーカーの場合は >>827
WebDirectが５台目で遅くなるか？事実上サーバー上での集計になるので。遅くなるなら構造の問題、ならないならネットワークの問題かな
どっちにしてもサーバー上のスクリプト実行ステップで計算結果をレコード保存がパフォ的には良さげかな
何でもスクリプトは反対派だけどパフォーマンス改善できるなら使うw >>831
繋がってるのは30くらいです
その中で、実行中が5スレッド位溜まると
激しく遅くなりますね もしかして、ウィルススキャンは除外してたりしませんかね？
こんだけ通信してるんで、リアルタイムスキャンされると
ヤバいかなぁと >>832
ゴメン台数は関係なくてWebDirectなら集計の為のデータ転送はなくなるはずだから状況の変化があるか気になった次第
遅くなるとき鯖のUIも緩慢になるならスワップアウトとか発生してない？ 単価かける個数
レベルでもスクリプトで書いてる俺っておかしいのかと思ってたがそうでもないのかな
SUMの対象増えてくるとリスト表示で飛んてもなくカクつく
上に書いてあったように
週とか月の集計とかやると 単価かける個数レベルなら、同じテーブル内だったら自動入力の計算式に書くな。
入力済みなら計算しないのチェックを外してだけど。 ざっくりの説明なら。
計算式フィールドは参照が更新タイミング。
自動入力の計算式は関連するフィールドの更新時。インデックスも同じタイミングで更新される。 >>819
その合計フィールドはグローバルフィールド？ >>819
あまり賢くないので理解できない…
よかったらもう少し具体的に書いていただけませんか？ 例えばこんな売上リストがあったときに
商品名 個数 単価 金額
商品A 2 3000 6000
商品C 1 1500 1500
・
・
商品R 5 5000 25000
合計 123500
↑
グローバルフィールド
個数フィールドの個数を変更したときに金額フィールドや合計フィールドが計算フィールドだと売上レコードが数百数千万になると処理がつらくなるけど、スクリプトを２つ作って
スクリプト１
変数の設定（$$origin, 金額フィールド)
スクリプト２
フィールド設定（金額フィールド, 個数フィールド×単価フィールド）
レコードの確定（ダイアログなし）
フィールド設定（合計フィールド, 合計フィールド＋金額フィールドー$$origin)
レコードの確定（ダイアログなし）
スクリプト１は個数フィールドのOnObjectEnterで起動
スクリプト2は個数フィールドのOnObjectSaveで起動させる。
これだと他のレコードは関与しないのでレコード数が少なかろうが多かろうが処理に影響を与えなくなる。
ただし、最初に画面を表示させるときに合計を計算するスクリプトを作る必要はある。
上のは単純なモデルだけど複雑な計算（複雑なリレーションや何十個のフィールドを掛け合わせたり、合計小計平均など細かく計算するときなど）になるほど差分計算の方がパフォーマンス的に優位になる。 >>841
ありがとうございます
そのまま真似してみたけど
マイナスになってしまいます
最初に合計値を計算する必要がある、とあり
それをやってないのが原因だと思いますが
どういった処理になるのでしょうか？ 勤怠管理で人ごとに月ごと週ごとの集計とったりするのはどうやるといいんでしょうか？
年と月と週用自己リレーションはって
労働時間をSumしてそれぞれの合計値を出したり
前回の退勤から何時間たったかを計算などしていると重くなります
前回から何時間たったかはどこかの掲示板で教えてもらったものでよく理解はできていませんが
そのフィールドを消すと大分はやくなりますが
やはり全体的にもっさりです >>834
ありがとう
WebDirectが、まず分からず
こちらのバージョンは14なので、使えないのではと
サーバーは、スカスカなんで問題ないです
クライアントは、スクロールの度にかくかく祭りですが
クライアントのキャッシュを爆増させようかなとか
焼けになってきましたね ちょっと気になったのだけど、その画面レイアウト、リスト表示じゃね?
リストは対象の全レコードのデータを集計も含めて集めまくるからデータの多いものでは
そのまま使用しちゃダメだよ。
リストを表示する場合でも、予め表示項目のないフォーム画面に一旦移動し
そこで表示レコードを絞ってからリスト画面に切り替えるくらいの小細工は最低限しないと。
FileMakerのパフォーマンス・チューニングガイドにはその辺の小細工のネタが沢山あるから
一度は眼を通しておくと幸せが見つかるよ。 >>834
ごめんなさい、サーバーのｕｉって
サーバーでFmProを動かしてみるってことで好かね？
それやってみます 因みにブラウザ版ではなく
fmsで管理してるファイルに
クライアントがアクセスする形式で利用してます >847
「FileMaker パフォーマンスガイド」で検索すれば出てくるよ。 >>848
サーバーがメモリ不足でスワップ発生とかしたら、何の操作も激重になるから・・・でもスカスカということは関係ないのかな。 >>844
勤務時間に関するフィールドを更新するたびにスクリプトですべての関連レコードをSUM
たぶんよほどじゃないど一瞬だと思う
俺がわざわざそうする理由のひとつに
フィールドが増えてたくさん並んでて保守するときにどれが計算フィールドでどの式いれてたかごちゃごちゃになるから
スクリプトでやってるってのが大きい なんでもリレーションして計算している、それだけの原因 >>854
やっぱ取引先ごととかの集計に自己リレーションつかいまくるのは駄目なんだね
どうやるのが正解？ 覚えれば楽でスピードもリレーションより速いExecuteSQL リレーションはまだいいけど、ライブ計算フィールドを最低限にして
ルックアップやスクリプトで入れ込むフィールド固定値にする。
必要に応じて再計算するようにすればいい。
また、レイアウト上にポータルを並べて、それを複雑なリレーションで
全データからソートして表示、まして画像とかやってると重くて当たり前だし。
たとえば、表示させるのは一部だけなら、各レコードに旗立てて上位50
件をリレーション条件に入れてソートさせると軽くなる。
そういった工夫を重ねる。 SQLは速いと言うのは都市伝説
FMのSQLはオマケ程度に考える
使う場合は想定最大レコード数入れて実行速度測りながら実装する
数十万件超テーブルは要注意
JOINやサブクエリは鬼門 >>852
スカスカですね、
色々イジった結果、少しはマシになった気がします
後ほど整理して、ここで共有します
ただ、定間隔で起動するバッチ処理が動くと途端に重くなる気が
一日に扱うデータなんて100人分程度
そのトランザクションで考えても1000も行かないと思いつつも
数百万に到達してしまった
そのテーブル(画面でもスクリプトで参照)に対して取り込み処理が動き
更にマスタテーブルを更新するイメージ
一回、全件開いてるんじゃねー見たいな
重たさを感じる
ｃｓｖ等の取り込み処理のベストプラクティスみたいなのが有れば教えて頂きたいですわ
ロックでも掛かっているのか
何なのか、FileMakerって謎めいている その、数百万のテーブル、全レコードに索引はってるんだよな
そこが凄く気になっていた
oracleとかじゃ考えられない行動なので
FileMakerだと普通なのだろうか oracleだと、登録の負荷って低いけど
何か特殊な動きとあるんだろうか
またしても連投してしまった >>857
例えば今年の取引先ごとの売上なら
取引先と年で自己リレーションして
そこのレイアウトでつくるってこと？ インテックスは全レコードに張るものでしょ。
全フィールドと混同してない? >>859
そのインポート処理が追加ではなく更新で行っているとか? パッケージ版の共有はテストのみ
ということらしいが監視されてるわけてもないし
office365のライセンスみたいなもんだよね？
少なくとも中小零細企業にとっては 結局のところ
売上テーブルから今年のA社の売上を合計する
といったのはどうやるのが設計的にいいんでしょうか？
もちろんドロップダウンリストなどで各車切り替えて表示させる場合 >>863
失礼しました
全フィールドですね
項目数こそすくないですが ■ このスレッドは過去ログ倉庫に格納されています
