ファイルメーカーユーザの集い Part6
聞きたいこともあり、立ててみました
リンクとかは、2レス目以降でお願い致します 買ってくればなんとかなるもの
自分の見識を蓄積したDBという違いだね チャットGPTにファイルメーカーの内容聞いてみれば? FMを知らない奴はFMがいかに進化しているかを知らない、エクセルも同じ
昔のエクセルとは全く違う excelが進化したとしても表計算としてであって・・ >>212
具体的に「FMがいかに進化しているかを」教えてください >>213
エクセルは膨大なデータを抱えてライブで
運用はできない。去れよ、エクセル信者は。 FMで何百万、何千万レコード使ってんのか?俺は使ってるぞ
一万レコードにも見たないならエクセルでいいだろ
FMは今後ディスコンになる可能性だって秘めてるぞ >>216
エクセル君は自分の家に帰れよ
他所に来て暴れるのは子供だろ >>219
Appleに変わってから大きく変わってる FileMakerはGoと組み合わせて簡単にすぐ組めるのも強みだしな。
ぶっちゃけUI部分にはほかに代替できるソリューションがない状態。
それよりもServer有りだけの時でいいから、DB本体側のトランザクション能力の向上や
レイアウトではなくテーブル側のトリガを実現してほしいわ。 >>221
どういうこと?
あやふやにヒントだけだされても困る Excelでは不十分
Accessは古すぎる
ファイルメーカーは先行き不透明
一体零細の一人デジタル担当大臣の俺はどうやったらいいんだ?
自前で開発なんてできないしランサーズなんなで的確に伝えてなくて作ってもらえそうな気もしない >>223
収益が低すぎるAppleに変わってから怒涛のバージョンアップでしょ、しかも顧客はそんなバージョンアップ求めていないし
ここからは憶測だけれどApple的な収益の閾値を割ったら撤退あるんじゃないかな 最近のバージョンアップ内容って、サーバサイドの集計やループ処理関数やスクリプトトランザクションとか
割と顧客が欲しかった機能ばかりだと思うがなぁ。ubuntuでのサーバ稼働は運用コストを大きく下げたし。
JSON関連の関数はもはやないと困るレベル。
この調子でぜひとも正規表現のサポートとQRコード生成を実装してほしいです。 >>226
撤退してたらみんなどうする?
スタンドアロンなら古いまま使い続けてもなんの問題もなさそうだけどね
いまだにランタイム版使ってるし 実際のところ、オフラインで共有せず同時編集もしないとなるとExcelでVBA使って転機やりまくったほうが将来安泰なんですかね?
上記の用途の零細程度のデータ処理量だとVBAでもマシンパワーでなんとかなりそうだし
売上から請求書つくるにしても転記するのはせいぜい30 レコード、フィールドも100適度だと思うし >>228
無くなったのなんて幾らでもある、町工場は今でもPC-98だよ
エミュで強引に動かしたり
顧客の事なんてどうでもいい収益があるかないかだけ >>229
エクセルでなんとかなるのはデータの種類と項目が
少なくてLanする必要もないからで、だったらそのまま
使ってください。
このスレは一応リレーショナルデータベースのスレなんで。 >>229
レポート機能的なの使いたいときにそれごとにVBA書く必要あるけど即時性と共有しないなら十分かな 一般的仕入れ販売業務でも、在庫管理、顧客管理、売上げ管理
これらを有機的に連動させて、税務データまで流し込むとか
Excelではとうてい無理。
うちも給与計算だけはExcel、単一作業には向いてる。 中小はERPは外部に出すのがほとんどかな
伝票電子化、インボイス管理、税務と
ミロクか奉行がほとんどでしょ
ファイルメーカーで内製してしまうと
メンテの人員確保がむずかしいんでは? 業態が典型的ならそれが一番だと思うが、
あとは特殊性や規模との兼ね合い。 >>234
ああいうの使えるところうらやましい
と思ってたがどうやらExcelで対応して清書的にソフトに転記してりしてるみたいだね >>231
でもTOすら理解できずに明らかにExcelでやった方が早い、素人の作りかけを何度も作り直したけれど 収益からは無料というわけにはいかんのでは?
実行環境だけを提供するって気がする 無償版て、有料ユーザを育てるための餌。
たいていの場合はスタンドアロンとか、色々制限があるはず。 以前あったランタイムの代わり+α程度の位置づけじゃないの?
ESSとか外部SQLインポートとかあの辺がまるっと制限されそうな気がするなぁ。 MYSQLやPostgresqlをWebサーバーで立ててファイルメーカーの「URLからの挿入」で普通にデータのやり取り出来ちまうからなぁ。PHPあたりの知識があればランタイムやGOからDBMSに読み書きできる >>244
自分はそれやってるけど、リアルタイム処理は出来ないし、処理が複雑になって開発工程が難しくなるからあまりお勧めできない。
FileMaker上では正しい情報が表示されてたとしても、ジョイントプログラムにバグがあるといざサーバーのデータ見たら更新されてないとかもあるからチェックが煩雑になる。 >>244
ランタイムってcURL使えないから、全部GETで処理しなきゃいけないよ? ファイルメーカーで請求書とかつくってるとこは
今後電子化になったとしたら
PDF出力してなんらかのサービスにアップロードして送る感じを予定してますか? >>247
PDFにしてメールじゃないの?
給与明細は各従業員のメールに送信してるからそれと同じにするだろうけど、難色示すところが多いだろうからほぼ紙かな。 とあるテキストファイルを、一旦グローバルのテキストフィールド
に取り込みたいんだけど、どうしたらいい? >>249
オブジェクトフィールドしか無理、強引にやるならテキストファイルのテキストを抜き出してテキストとして入れる テキストデータとして扱ってもいいな普通のインポートで大丈夫jsonだといい感じにデータ生成出来るね >>249
データファイルから読み取るスクリプトステップで処理するのが簡単かな? テクストデータとして取り込もうとすると
行やカンマ事に1レコードとして切ろうと
して困るんだよね >>253
データファイルから読み取るだとテキスト丸ごと一つの値だよ? すまん、その前のバージョンなんで。
開いてコピペするか、スクリプト書いて
仮想連動するしかないかも。 >>256
おめー、役に立ったかどうかを置いといてまずは時間割いてもらったんだからお礼だろ死ねよ それは失礼した。「すまん」で総括したつもりだった。 素直で素晴らしい!何でも聞いてくれ!
これでもfm7から欠かさず毎日FMを触ってる
ディスリまくってるけれど、FMに出会わなければ今の自分は無かった FileMakerもキーとダウンロード方式移行で
新規購入しないと使えなくなった。以前のverも手軽に手に入らない。
これって不正使用は減るけど、ユーザも育たないような。 FMっていつも世間の流れから一歩か二歩は遅れるんだよな
FMSのJAVA問題なんて何年やったんだよ ODBCの利用の仕方が未だにわからないです。
わかりやすい解説サイトとかあったら教えてください。 そんなの使わなければ大丈夫ですよ。悩みがなくなりましたね。 いつもここや他の掲示板みて思うけれど、FBAが個々にやってるトレーニングに申し込んで徹底的に基礎から学んだ方がいいよ
FMは何となくで出来てしまうところがあるから基礎が全然分かってないのにトリッキーな質問してアホやなといつと思う。 >>264
> トリッキーな質問
って何?
具体的にヨロしく 基本が分かってればそんな周りくどい方法を考えないってこと ファイルメーカー歴15年
日本のファイルメーカー使いの中でも間違いなくトップレベルだとは思うけど
ファイルメーカーでの開発者の給与安すぎて草も生えん
せめてフルリモートで開発だけやってて年収700万くらいになりたかった ボディパート使わずに集計パートだけにするって普通の運用ですか?
レポートだすときに任意のフィルタでレコードをグループ化して表示させたいのでそうしてます
普通は別のやり方でやるものですか? >>267
独立すればいいじゃん、クライアントは何使おうが要望に答えてくれれば文句ないよ
だからこそのFMなんだよ、他の開発環境より圧倒的に時間がかからない、でも費用は同じかそれ以上請求すればいい。 >>268
Atb-Btb
この二つとリレーションにグローバルフィールドを使う
仮にBテーブルには科目があるとする、「数学」「科学」「日本史」
Aテーブルにはその科目にグローバルフィールドのリレーションを引っ張る、Aテーブルのグローバルフィールドに「数学」と入れればBテーブルの数学のみが抽出される
答えなんて無いけれど、FMならこれがシンプルで発展性があるんじゃないかな >>270
そんなやり方もあるんですね
やっぱFMは力技というか迂回作が必要ですね
ちなみに今回想定していたグループ化は
売上レコードの売上種別で判断して
売上種別1 は日計
売上種別2 は月計
売上種別3 はレコードこのまま
でレポートに羅列させる
ってイメージでした
伝わりにくくてすみません
これもなんともなりますか?
グループ化したい種別ごとに自己リレーションしてそれぞれSUMするフィールドを作るしかないんですかね?
動作的に遅くなるのかはわからないけど
ごちゃごちゃして不安ではあります FMってもともとは素人が手軽にDBを作れるようにと
企画された製品だろ?
基本が〜とか、そこを叩いてなんの意味があるのか? >>269
ファイルメーカー開発って
誰でも簡単に出来る!って認知されてるから
安く買い叩かれない?
しかも基本的にクライアントの分だけライセンスも購入で割高になって.Netアプリとかと比べると使用コストもあって不利だったり
ファイルメーカーが有利に働くのって
社内で自製アプリで頻繁なアップデートが必要な場合に
安いエンジニアを雇って更新や開発を任せるくらいしかなくない? 俺は昔に客からの案件でファイルメーカーアプリを作ったときの話。
スクリプトとかデータベース定義など触れない権限でウチがメンテ代を毎月30000円貰う契約だった。
メンテ中にキーロガーで開発用パスワードを暴かれて突然契約を切られたことがある。
そこからは改造されたり自分たちでメンテしてんだろうなと予想。
少し弄れば自分たちが作ったことにして他社に売ることだって出来るしな。 専業プログラマー向けの開発環境が求められるんだろうね >>274
契約書に普通はリバースエンジニア禁止項目がある筈、訴えればかなりの大金取れる
時効迎えてないなら弁護士に相談した方がいい >>271
リレーションで日付を大なり小なりするだけ >>273
認知されてないクライアントを探すFM界隈にするとFMを過大評価してしまうけれどFMの認知度なんて秀丸のシリアルキーぐらい 前にも書いたけれどマジでFMのトレーニングに行った方がいいよ
費用も時間もかかるけれど習得した技術は一生物の資本になる >>273
個人的にはCとOracleで作ろうとFMで作ろうと成果物が同じなら同じ単価を貰っていいと思う
事実俺は貰っている、恐らくはFM界では一番単価が高い開発者だとは思う
FMの開発者はFMだから安い単価なんてコンプレックス抱く必要はない
Pythonなんて見方を変えればFMより楽なのに調子に乗った単価取ってるじゃん >>274
冷静に考えたらかなり悪質な奴だな、admin権限抜いてメンテしなければいけなくなる
顧客も結局はマイナスになるのに
次からはリバースエンジニアしたら賠償金一億と名記するといいよ >>281
俺は時間あたり8000円取ってるけど
ひょっとして10000円とか取ってる人?
どんな経歴??くわしく! >>283
人月でいうと300万円、ずっと同じソリューションで食べてる
実際にはコンサル込みの意味合いが強い 数学などの科目テーブルを作った様に日付だけのテーブルを作る
2023/02/28<
でリレーションすれば3月1日まで出るでしょ
月でやりたきゃdate関数、年でやりたきゃyear関数 あと俺が言ったのは力技でも何でもなくてFMの基本、SQLとは違ってFMはリレーションを如何に使いこなすかが肝
その調子ならindexがないとかでどうせ困るよ その事をFMがテキストで明示しないのが俺はいけないと思う、なまじaccessやSQL齧ってると出来ないことだらけと感じてしまう
ここに限らず質問者に対して奇々怪界なカスタム関数進めたり、破綻が見え見えの再帰関数を勧める奴見てリレーションなら一発なのにといつも思ってる
絶版だからPDF版の経典を先生のところから買いなよ
「リレーションを極める」
何だかんだ言ってFM使いこなしてるやつはこれがベースなんだよ >>286
monthだったねw
このリレーションに頼るのがFMの足を引っ張っている面もある
パフォーマンスがやはり落ちる、パフォーマンスが必要な時には極力リレーションの数を減らして1:1にする
ExecuteSQLの登場がリレーションありきのFMへの回答だったんだけれど、性能が悪いわなw >>284
やべぇ
どんなコンサル?どんなアプリつくってんの? >>286
それだと
2023/03/09 100 日まとめ
2023/03/09 200 日まとめ
2023/03/09 5 月まとめ
2023/03/09 5 月まとめ
を
2023/03/09 300
2023/03 10
にできなくない? >>289
ExecuteSQLはそのまま使うとローカルのオカレンスに対して行うことになるから
元々のSQLエンジンとしての性能が高くないのに加えてテーブルデータをまるっと持ってきてしまう分
パフォーマンスが低い。回避しようとすればサーバ側に一旦投げて結果を得る様にするとか工夫が必要。
ただ、ExecuteSQLはオカレンスに頼らずに済むのと、リレーション先がインデックスが作れないフィールドでもOKなので
地味に活躍するけどね。 >>291
集計したい単位でリレーション元を開始、終了で日付範囲を自前で計算して設定してやればいいだけだと思うけど。 >>290
FM7の頃から作ってバージョンアップを重ねてきたからね新規参入は無理なソリューション、元々俺がその業界に強かったから土台はあった
NDAきっちり作ってミソとなる部分は絶対に他言させない様にしている
大手に億と払って頼んでも失敗すると思う
でも、俺に頼めば失敗しないから >>293
自前で計算って?
Accessでいうグループ化
Excelだとピボットテーブルがやりたいんってことなんだろう shinさんが生きてたらまた違う世界線もあったのかもね >>296
お前はセンスないから諦めろ、諦めも大切だ
他の才能があるかもよ何もない可能性もあるけれどな >>298
こういう中途半端でえらそうなやつしかいないからユーザー増えないんだろうな
ExcelやAccessではこんなやついないもんな >>299
お前が適切に分かりやすく答えてやれよ、そもそも質問してる奴の日本語が怪しいのに答えられねーよな?
だから、切ってやるのが優しさなんだよ >>301
読解力ないだけじゃない?
単に標準機能でレコードのグループ化がないからそれをやりたいってだけにしか読解できないけど?
例えば日付や月、年、項目ごとなど