ファイルメーカーユーザの集い Part4 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
前スレ
ファイルメーカーユーザの集い Part3
http://mevius.2ch.net/test/read.cgi/bsoft/1397631123/
◆メーカーサイト
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/
質問・相談は環境・バージョンを忘れずに。テンプレ以上。 >>283
ファイルメーカーで下請けごとに金額かえたり
レコードをグループ化するのが大変
グループがないのは半かなり不便ですね、
分類でまとめて1レコードとしてあつかう、とかができない ちなみにEXCELから売上管理を移行中だけど3年ほどたっても完成してない
細かいとこまでこだわってしまうフォントやレイアウトに費やす時間がおおい 売上のテーブルと下請け業務発注テーブルと経費テーブル、仕入れテーブルは分けるべきですか？
フィールドやテーブルは増えて、正規化できてるようにも見えないけど
出納帳みたいに粗利だすならこうですか？ FMからVBSやWSHで動かそうとするとなかなかだな >>286
おいおい 怖いこと言うなよ
手書きの帳面でもそれは分けるだろ >>284-286
一度、何かの教材に沿って一本作ってみた方がいいかもね。
あるいは自分で一から作るのではなく、サンプルを自分の思うように
変えるとか。 >>288
>>289
正規化はわかってるんですけど
FMはクエリもないし非連結フィールドもないので
テーブルをわけると計算がやりにくいんですよね
レコードのグループ化もないし
例えば売上カラ経費を引くとき、その計算結果をどちらかのテーブルに保持しなければなりませんが
どっちに保存すんだよって思います >>290
誰に文句言われる訳じゃなし、好きに作ったらいいんじゃない？ ファイルメーカーは一般的なDBの理論は通用しないからね
バカみたいなフィールド数になる 売上テーブル
仕入テーブル
作って月ごとの売上求めるのにも自己リレーションとそれを集計する計算フィールド
月ごとの売上-仕入やるのも計算フィールドがいる
しかもその計算フィールドは売上か仕入のどちらかに置く必要があり
月ごと年ごとなど、それぞれ自己リレーションと計算フィールドがいる
集計フィールドつかえっていわれそうだけど
あれは使いにくいし、レイアウトに集計額配置するときなどに柔軟性もない
いちいちパートとか作らなきゃいけない
ましてや集計同士の計算なんて…… リレーションは必要最小限度にして、スクリプトなりで現在値などを
入れ込む仕様にするのも手。その分軽くもなる。 おれは一般業種で作ってないからその辺はわからんけど、
例えば、その日の取引の一覧を画面なり帳簿なりのための
レイアウトがあるとする。
取引先ごとの取引総回数だの、取引内容（商品）の割合とか
いちいち計算していたら処理が重くなるんで、
取引時に固定値としてフィールドに入れて更新していけばいい。
その固定値を一覧表示すれば軽い。早い。
あまり良い例じゃないかもだが、なんでもリレーション
する必要はないんだよね。FMはスクリプトを併用すべき。 毎年この時期に新しいファイルメーカー でるけど今年はいつかな？
昨年は第２週だっけ？ >>297
固定値ってのはレコードが増えるたびにスクリプトで足し算していくとかそういうこと？ >>299
例えば何回目の取引とか、取引のときにひっぱって「取引回数」って
フィールドに入れちゃう。この数は基本的に取引時に変更するものなんで、
ライブでなくてもいい。
取引時の年齢とかと同じで、ルックアップの延長ってことかな。 スクリプトトリガで起動して変数を配列みたいにloopで回して計算結果をフィールドに挿入でしょ >>301
初心者なんでよくわかりません
何をLOOPでまわすんですか？ スクリプトでリレーションから計算してフィールド設定。
あるいはルックアップ。
要はそのときそのときに計算させて、他の作業はその値を使う。
一覧表で様々な情報を表示するケースを考えて、
どうしたら重くなるかを想像すればわかる。
実際にやってから聞いてくれ。 月間集計とかも、全部をリレーションでやって、挙げ句の果てに
ポータルに全データのソートも入れ込むとかするとかを避ける。
月の集計なんて当月以外はライブである必要なんてないから。 >>306
月間や週間の集計は、レコードが増えたときにスクリプトで計算フィールドに数値として保存するってこと？
それをやるにしても、求める集計ごとに自己リレーション必要じゃないですか？ レコードが増えたときなら、ルップアップデもできる。
計算フィールドでなく数値フィールドに保管だ。
リレーションするだけと、リレーションで計算させるのとは違うし、
計算させる数字を予め保管する手もあるし、スクリプトで必要時に
集計させる手もある。
まぁ、色々やってから確認してくれ。
今の発想だと超重いDBが出来上がる。後で容易に修正できるのも
FMの少ない利点の一つ。 基本的に計算フィールドはつかわずにスクリプトで計算して数値保存してます
レコード増えたときはルックアップでいいけど
変更や削除したときはどうやってますか？ >>309
フィールドにフォーカスが入ったらトリガでスクリプト起動。グローバル変数にその時の値を入れる。レコードを削除や変更したらその値を変数にとってグローバル変数から足し引きして値を保存する。 それが一般的なのかな。
俺の場合は、そもそも新規レコードはスクリプトでしか作れない
ようにしているし。 >>313
集計したいグループごときグローバルを用意しておく、ということですか？ >>314
エクセルからファイルメーカーに移った人と、プログラムやっててファイルメーカー使ってる人で違うんじゃない？
エクセルの延長だとどうしても計算フィールドや集計フィールド多用するんで、リレーション張りまくって重くなりがちになる。
プログラム出身は変数計算に慣れてるから、値取得してloopぶん回して計算してDBには計算結果のみ保存って感覚になる。
ファイルメーカーも変数の繰り返しに変数入れたら配列もどきになるし、ファイルメーカー社もそうしろってことなんじゃないかな？ >>315
そうことだね。
グループの数が時々で変わるなら、そのレイアウト表示時に
変数の設定 $total. ←グループの数を入れる
変数の設定 $i. 0
Loop
変数の設定 $$group. 0. 繰り返し$i
Exit Loop if( $i < $total
変数の設定 $i $i +1
End
でグローバル変数$$groupを初期化する。
(別にしなくてもいけるんだけど、デバッグの時に初期値かどうか知りたいんでそうしてる。) 集計の計算したい時に集計フィールド配置するんじゃなくて、スクリプト使ってレコードやポータルで変数計算させんのよ
レイアウトの切り替え データのレイアウト
検索実行(グループのキー)
レコードの移動(最初)
変数の設定 $n =0
Loop
変数の設定 $n. $n + 計算したいフィールド
次のレコードへ(最後まで来たら終了)
End
レイアウトの移動 元のレイアウト
フィールドの設定 結果フィールド $n
ポータルなら
ポータルフィルタでグループを表示
オブジェクトの移動 ポータル名
ポータル行の移動(最初)
変数の設定 $n =0
Loop
変数の設定 $n. $n + 計算したいフィールド
ポータル行の移動 次へ(最後まで来たら終了)
End
フィールドの設定 結果フィールド $n
こんな感じ >>319
スクリプト動かす度にすべての対象レコード出集計しなおすんですか？
レコード増えたら重くなりません？ >>320
集計すんのは最初だけで、あとは差分を足し引きすんのよ
>>313
のやり方 >>321
最初に計算するときに>>319をやって
あとは>>313ってことですか？
グローバル変数はフィールドに保存しないんですか？
リセットされますよね？ 上下の表示域を少しでも大きく取りたい
昔風の横ステータスを疑似で作れないか
問題はレコード位置と移動のスライダー >>322
グローバル変数はファイルを閉じるまで消えないよ。 ＞このレコードはすでに別のウインドウで変更中のため、このウインドウでは変更できません。
なんなんだ、これ >>328
ポータル行編集中のまま新規ウインドウを開こうとして、自分自身でレコードロックしてない？
新規ウインドウの前に、レコード確定入れてみて。 なるほど、いちいち「 レコード/検索条件確定[] 」いれなきゃならんのか >>326
スクリプトで計算して数字でフィールドに格納するのでは駄目なの？
集計って月間とか週間の取引先ごとの売上とかのことだよね？ 特定の状況下のフィールド設定であの表示が出るという問題ね。
一応念のため。 vectorに紹介されてるフリー販売管理ソフトとか使ったことある人います？？？ 17の案内きてるけど、オンプレミスで事務処理してると
14位からぜんぜん欲しくならないよ アドバンスに一本化なんだね。
サーバーも単体で売ってたの無くなったのかな？ 自己リレーション不要になったとかうれしいね
マスタ詳細ってのは何でしょうか？ Proがなくなって、1〜4人で利用するところは、切り捨てることになるね。
税込62000円のAdvancedを買わないと、なにも出来ないのだから、FileMakerを使うのに敷居が高くなった。
もともと個人の層から広まったソフトなのに、そこを切り捨ててどうすんだという話。
FileMakerというプラットフォームの先行きに不安を感じる・・・ まじかいな@Proユーザー
そうは言ってもランタイム作成機能とデバッガは欲しいと思ってはいるのだけど
でもランタイム機能はそのうち切り捨ての噂もあるよね... ランタイムは廃止予定になっているから、廃止されると、FileMakerから他の言語に移行してアプリを作成せざるえなくなる。
リトルビジネス用に、極めて低価格でFileMakerを利用できるようになればいいんだが。 >>339
macOS も野良アプリ撲滅に向けて頑張ってるから、FileMaker でランタイムアプリ作っても配布出来ない状態だし、世の中の流れなのかもね。 >>340
あまり詳しくないのですが、
Macは、アップルの、App Storeで、ランタイムアプリを配布出来ないということですか？
他のVectorとかからランタイム版をダウンロードして実行できますよね？ >>341
Apple に登録した Developer id の署名をアプリ内に埋め込まないとGatekeeperに撥ねられてしまう。 App Store でFMのランタイムは見たことがない。
Appleの審査通るんだろうか？ >>319
月ごとなんかの自己リレーションでsumやったほうが
動作もメンテも速くない？ >>346
macOS のゲートキーパー通り抜けられないアプリ。
Appleに開発者登録してないと通り抜けられないの。 末端ユーザーは入力するだけなんだから編集機能のないStanderdみたいなのが欲しいぐらいなのにまさかAdvancedオンリーになるとは ランタイム廃止の方向性を合わせて考えると、代わりにPC向けにもGoみたいな実行専用環境をフリーで配布するとか
…ないか
あっても俺らみたいな自分で手軽に作って自分で使うライトユーザーは置いてけぼりくらうだけだな
最低ラインを足切りするなら、せめてAndorid向けも作れるようになるとかLinux版も用意してくれる
とかして欲しいもんだ 桐できりきり舞いとか言われてたな
未だに変な日本語呪文なのか UIに関してはACCESSよりもかっこいいのがつくれるような気がしたけど
やっぱ細かい部分でつらいところがあるよね
クロス集計とか非連結とか集計関係とか
そもそも目的はDBであってデザインやるわけじゃないからACCESSに戻るかなぁと思案中 業務に使うにはFMはやや不向きだよね
感嘆にコレクション管理とか読書記録とか作るにはいいけど
可変フィールド高すらないからねえ……
前持って大きめにつくってスライドさせるしかないとか……
ACCESSなら入力しただけ自動で高さ変わるのに そうかな
おれは5からのユーザで書類画像含めて30ファイル構成で
運用してるけど、けっこうやれるよ。
ただ、fp7,fmp12と機能は増えたがそういう用途には逆行
しているように感じる。 グラフの実装とネットブラウザあたりまえだったなあ、わくてか FileMakerの開発環境が貧弱なのも不満な点だなぁ。
Visual Studioが神すぎるから比較するのは無理だけど、
FMのスクリプトエディタは、一行書くのにクリックするところが多くて手数が多すぎる。
あと、データが壊れたときの修復回復が面倒なのもFMの限界だわ。
メニューにある修復は、データを取り出すためのものであって、壊れていないのが確定しているファイルに
修復したファイルのデータをインポートするのが正しい、となっているから、手間がかかる。 つー感じで、求められる方向性がばらばらなんだよね
だから製品も中途半端になっちゃう 絶対業務に使うのは想定してないよね
なんかそういう売り方もしてるけど単にデータの蓄積することだけで
計算や分析とかやるのはきついよね >>357
普通に業務で使っているところ多いだろ。
分析は知らんが。 分析だけが業務じゃないわけで
自分の用途に合わないってだけじゃないんかな
インターネット越しに何台ものiPhoneやiPadでアクセスして、画像や動画やデータをリアルタイムで集積していく、
みたいな”業務”だとファイルメーカーにかなりの部があるのでは？
慣れというか、自分のアクセスのノウハウがそのまま応用できるかどうか、ってとこの問題も
半分くらいありそうな感じもする
データ分析ってほどのものはファイルメーカーで組んだことないからノウハウわからんけど >>359
多いのかな？
顧客管理とか従業員管理がメインじゃない？
販売管理とか請求書とか複雑な計算が絡むのはあまりないイメージ 17入れてみたけどGoogleのIMEの変換候補がフィールドにかぶって使い物にならないな
完全に入力中の文字が見えない
これ致命的なバグだろ フォントによっては勝手にデフォルトのMSゴに変えられたりするバグもそのままだしな
欧文フォントのフィールドに全角入力してもMSゴにされる
変換で半角にして確定しても駄目
極めつけはデフォルトのフォントを変更することもできない
DB以前にソフトとして不完全すぎる
レイアウトの綺麗さなんかも売りにしてるわりには適当すぎ >>362
こういうipadを活用しているところって
端末を買い足したときなどにiosのバージョンが変わったり古いiosがGOから見捨てられたときは全部買い直したり
金払って修正してもらってるの？
このサイトで指定されているような問題への対処
iOS用の業務アプリ開発を勧めない理由（ワケ）
http://gmba.jp/2015-02-19-15-20-41/44-opinions/1219-opinion-oishi-vol2.html >>319
こういう具合にしなきゃ重いってのは
i7やi5でSSDのマシンパワーゴリ押しでも解決しないの？
貧弱なPCでも動くように、ってこと？ >>363
俺も見えなくなる
どのIMEでもそうなるからFMのバグなんだろうな
17ってとくに機能増えてるわけでもなさそうだから16のままつかうかな 16のスクリプトのタブで日本語変換がまともに動かないバグは
とうとう治らなかった
もう2バイト圏のためのプログラミングが出来ん模様 >>369
やっぱファイルメーカーは将来性ないのかな
なんか細かいとこがテキトーって感じするんだよね
ACCESSに移行したほうがいいのかもしれないけど
共有というか同時接続がねえ >>368
FMよりもWindowsの側のバグでは？
WindowsではFM使ってないけど他のソフトで同様のうっとおしいことあったような… >>371
16ではならないけど17ではなるからねえ
よかったら評価版いれてたしかめてみてください
僕だけのバグなのかが知りたいです 最大登録者数で接続〜
って表示が出る
共有のところで２つ表示されるのが問題なのか？ IPv6を切れば大丈夫だったか、なんでかはわからん FileMakerを業務で使用するのは徐々にやめることにした。
開発が速い、共有が簡単というのはいいんだが、
ライセンス体系の変更などファイルメーカー社の方針についていけん。 >>376
ACCESSにするの？
共有どうしたらいいんだろ
仕事に使うならACCESSのほうが何かと安心かなあとは思う
情報も多いし
遊びで使うなら断然ファイルメーカーだけど フォント関係のバグ治ると思ってただけに17にはがっかり
IMEのバグでてるし >>379
Windows10Proで標準のIMEだと普通に使えてるから、どんな状態になるのか画像見てみたい。
昔からGoogle IMEとの相性悪いよね。 EXCELじゃおいつかなくなったのでDBにするとして
ファイルメーカーとACCESSどっちがいいんですかね？
販売管理
経費管理
それらから粗利をだす簡易的な出納帳
請求書
を作るシステムをつくります 経理をやるのなら、専任置かないとね
先任者を確保する選考理由としてどんなソフトを使うか判断でしょ
能力の高い個人が利用するのなら会社でのファイルメーカーもありというくらい ■ このスレッドは過去ログ倉庫に格納されています
