ファイルメーカーユーザの集い 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/
質問・相談は環境・バージョンを忘れずに。テンプレ以上。 フィールドの上下の大きさが大きすぎるんじゃないの?
だから目一杯ポータルに入れようとしてるとか。 >>195
ポータルにサイズピッタリのフィールドをいれる
フィールドの文字を高さの中央寄せにする
文字がポータルの行の中央にこない
こうならずに
https://i.imgur.com/zTKDmv5.gif
こうなる(欄のやや上に寄る)
https://i.imgur.com/jgu9otJ.png
ということです 基線なんてもんがなけりゃなんの問題もないのにな
そもそもフォントサイズに左右されてフィールドの最小サイズも固定されてるし
日本で売る気あるんだろうか?
MSは日本市場のためにExcelの線種増やしたってのに >>196
だから1行目がおかしいっていってるの、アフォかと ポータルにすきまなくフィールドを配置するという
思い込みに左右されている。その必要は全くない。 >>199
フィールドとポータル行同じにしないと無駄なスペースできるじゃん >>201
思い込みが激しすぎる。
あんたのサンプルの上の方エクセルのもセルいっぱいじゃない。
FMですきまができるのように思えるのはレイアウト画面上であって、
このエクセルと同じ表示がFMできる。
目一杯配置するとか、糖質みたいな思い込みは棄てろ。 島本町民以外の皆さん
大阪府三島郡島本町では
「いじめはいじめられた本人が悪い」ということですよ わざわざ下に置いてるのにw この人はどうしようもない。 まず、ぴっちりExcelみたいに上下の高さを1ミリもずらさずに高さ中央寄せみたいなのはファイルメーカーではできないよ
>>203
は何がやりたかったのかわからんが
中央寄せにこだわるなっていいたかったのかな?
中央に寄せたいといってるやつに中央寄せにするなってアドバイスするのも違うと思うけどな
どちらにせよ、ファイルメーカーではパンディングやフィールド位置をずらすなどの目分量でしかできません >>196で 基線が邪魔で上によるのが問題なんだろ?
中央寄せとかそれはレイアウト上の機能であって、実施的に意味があるのか?
問題を解決するのに道具ばかり見ている人だろ。 ちなみに、デフォルトの状態のフォント自動指定のフィールド大では
フィールドの中央より上に表示されてしまう。ポータルで中央表示は
不可能。
フォントを小さくすればいいけど、それじゃね。 なので、自分でフィールドの高さを可能な限り小さく数値指定する。
但し、全角の日本語は余裕が小さいので、少しごまかしがいる。 >>209
請求書とか印刷するときに欄の中央に表示したいじゃん?
ポータルじゃなくてボディに表示させてもぴっちり中央にならないよ 211に書いた
実際に運用時はフォントサイズを変えたりするわけではないので
真ん中になるようにしてあげればいい。
少しお化粧した先ほどの表の下に配置してみた。「8888」
左がデフォルト、真ん中が高さ変更、右がフィールドと枠の別表示
http://whitecats.dip.jp/up/download/1516455665/attach/
ファイルメーカーに限らず開発ってそういうもんだろ?
Webやってる人ならわかるはず。 お分かりになる方、ご教示いただければ幸いです。
オンプレのFM10をFilemaker Cloud(FM16)に移行しました。
レコード数は20万ほど。
オンプレのときよりは重くなりましたが、レイアウト表示等はまあそこそこ使えています。
が、レコードのエクスポートが非常に時間がかかり、かつFM16Proが途中で落ちるなどして
非常に困っています。
エクスポートするのは30フィールドくらいで10万レコードくらいです。
外部連携のため、現状は上記を行わざるを得ず、です。
オンプレの時は30分くらいで終わっていましたが、クラウドにあげてからは
3時間経過したところで半分も終わっておらず、かつ気づいたらFM16Proが
落ちていました。
AWSとの通信速度が10Mも出ておらず、そこが根本の原因だとは思うのですが
こちらは早々に回避できそうにないので、何かFM側で対応できないかと。
一旦サーバー側でエクスポートしたのちに、ファイルをまとめてダウンロード
できれば、と思ったのですが、Filemaker cloudはサーバスクリプト非対応
とのこと。
本日中に解消が必須でして、もしアイデアをお持ちのかたいらっしゃいましたら
何卒宜しくお願い致します。 平行稼働させるか、元に戻すのが先決でしょ
原因追求や対策は時間を作って後日だと思うけど
十分テストしてからじゃないと以降も問題出るよ >>214
>Filemaker cloudはサーバスクリプト非対応
これどこ情報?
サーバー上のスクリプト実行も出来るし、スケジュールも使えるよ。
(スケジュールの方はadminコンソールにその設定画面は無く、Admin APIを介して設定) かかってきた電話番号を表示させるのって難しいのかな。
連動すれば誰かわかるし、スマホが多い最近はどんどん追加登録
できると、精度が上がる。 >>217
CTI FleMaker でググれっ! 同じファイルの中でのリレーションと
別ファイルのテーブルを参照するリレーションとでは
速度に差はありますか?
あったとしても誤差レベルですか? >>221
自己リレおそいんだ
でもファイルメーカーでは自己リレは多様するしかないよね
使わないと同じIDのものを足す、とか単純なことができないからなあ
それもこれも非連結フィールドがないからなんだけどね
集計フィールドは遅くてつかいにくいし その手のリレーションは1レコード参照なんでまだいいよ。
例えば、取引伝票に名簿や商品ひっぱり、それを日計表にって
何でもリレーションしちゃうとクライアントでは使えない代物になる。
ルックアップやスクリプト入れ込みで一旦完結させないとね。
よくある改行入れたひらがなでの名簿牽引、自己リレで遅かったので
別にしてみたらクライアントで5倍速になった。 >>223
基本的に計算フィールドはつかわずに
スクリプトで計算して数値でいれてる 出納帳的なものつくるなら自己必須だよね
同じ月 同じ年 日毎に足し引きする
それぞれキーフィールド必要だし
それぞれに自己リレいるとか、正気の沙汰とは思えない
ACCESSみたいに非連結フィールド配置してその場その場で計算すりゃいいのに…
そもそもファイルメーカーは、計算系については力いれてないのかな
顧客名簿管理とかがメインって気がする フィールドもファイルもテーブルも、階層と名前だけで
引っ張るという珍しい構造なんで。 Excelからインポートするとき
ユニークな日付ごとに親テーブルにレコードつくって、それ以外は一対多で子テーブルへ
ってのはどうやったらできますか?
普段は親子関係で日付入力して、ポータルで子テーブルにレコード追加していってるけど
インポートのときにどうやるかわかりません 一旦取り込んで振り分けるようなスクリプト組まないとできません 一回きりでいいなら、臨時で子テーブルから親テーブルへレコード作成可能にして、親テーブルのキーフィールドをLoopで設定して回せばええのちゃうのん。 その昔、AppleScriptやwshと同期ができなくて、背中
押すだけの連携しか取れなかったが、改善された? 子側にインポートして集計フィールドの一覧を取り
親側で一覧をuniquevaluesかけてからレコード作成 親1と子1でリレーション組んで
1対多でポータル入力する
そのポータルに子2のフィールドも配置したとき
親2と子2でも1対多でレコードを作成するにはどうやったらいいですか?
親2に、ポータル上の子2を1レコードに集計したものが作成されていけばいいです
もちろん修正や削除したら親2も変更されるようにしたいです 遺産となった「繰り返しフィールド」で未だに苦しむことがある ☆ 私たち日本人の、日本国憲法を改正しましょう。現在、
衆議員と参議院の両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ あんな便利なものないじゃないですかぁ 繰り返しフィールド WEBプログラミングでも同じだけど、前に自分で作った
コードが理解出来ないことがあるんだよねw 困ったもんだ。 >>241
すげーわかるw
コメント書かなきゃって思うんだけどねぇ。 リレーション貼るためにつくった
メイン_集計用
とかそういうのが何が何かわからなくなる
あとどのフィールドがどの計算に使ってるかとか視覚化できないからごちゃごちゃになる リレーションの設定画面こそ、リスト含めて
確認できるようにして欲しい。 アクセスでいうところのグループ化をしようものなら
いちいちテーブルを用意してLOOPでそこに書き出さないといけない
こんな面倒なファイルメーカー >>246
それだと削除とか変更に対応できなくない?
俺はよくわからないけど、下記のようにしてる
ほんとグループ化とか非連結とかないのは不便だよね
(グループ化)
自己リレしてIDとかグループフラグか名前なんかで集計して、
最小か最大値のIDで表示・非表示設定してグループ化してる
ID フラグ 数値 グループ
001 111 100 ←非表示にする
002 111 200 300 ←表示させる
003 222 100 100 ←表示させる https://community.filemaker.com/thread/139805
これの解決方法知りませんか?
サーバーマシンのIP固定して立ち上げるとまさにこの状態、どうにも変わらない。 >>248
・表示が違うだけで実害無いので放置
・サーバーの展開をし直す、httpd.confはバックアップしとけば大丈夫でしょ。
のどちらか。 ビジネスじゃないけどw
ファイルメーカーで専用ブラウザ作れないかな
したらばとかね フォントを設定しても強制的にMSゴシックにされるんだけど
どうやったら変更できる?
ファイルメーカー16 ・フィールドのフォントを欧文に設定
・IMEを日本語入力にして英数を入力
・変換で半角数字にして確定
・勝手にMS Pゴシックになる (変換前に全角がフィールドに入ったからだとと思う)
回避するには入力値の制限みたいなとこの
計算式でフォントを強制変更する式を書く必要がある
ファイルメーカーって欠陥品だろ
そりゃシェアとれるわけないよな これってなにをするものなん?
小さいブラウン管、一体式
マキントッシュで動ごかしていた
ファイルメーカー 色々問題はあるがAccessよりはやりやすいかな
AccessはVBA書きまくる必要があるからバグが生まれやすい
かといってファイルメーカーもできないことが多すぎる
>>254
小さい会社の社長が自力で売上管理つくったり
個人のコレクション管理とかだろうな >>255
WSHと連携してカードの読み取みとかやってるが、
慣れれば職場でもそれなりに使ってくれるてるよ。 >>259
いつも5月ごろじゃなかった?
何がかわるんだろ 源ノ角ゴシック使うとデフォルトのMSゴシックになるね
一体どんなバグなんだ?
Excelなんかではふつうだからファイルメーカーの問題だよね ファイルメーカーのファイルを配布するときOSにないフォントをつかうとズレますよね?
例えば会社で複数台でつかうとき、手動でフォントを入れて回る必要がありますか?
フォント自体はフリーのものを使いますのでライセンスの問題はありません 全部に入れるしかない
しょせんDBなんで、特殊な記号とかでない限り標準で作れよ >>264
請求書とかはそれなりのフォントつかいたいんだよね >>266
IPAexとか源ノ角、数字はORCBあたり >>261
いれてみたけどなるね
源ノ角が欧文として認識されてるんじゃないかな?
だから2バイト文字いれるとデフォルトフォントになるという
なんでこんなことになるんだろう リレーションでソートして、それをポータルに一覧
したりすると超重いことがある。
ただ単に最新のものから逆転表示したいだけなんだけどな。 全部を表示する必要がなければ、一致するレコードを減らすキーを設定 xslmのインポートができないのはきつくないですか?
みんないちいち変換してやってるんですか? 入社した会社が販売管理業務をファイルメーカーでやってるけども、請求合計金額が合わないという致命的な不具合がある
社内高齢化が進んでpcに詳しくない人ばっかりだから外注のSEに販売管理システムは丸投げしてる状態がずっと続いているらしい。
所々使いにくいのでクラウド型販売管理ソフトに移行したいのだけれど、社員10人前後の中小企業には何が最適なのだろう システムに合わせて事務処理の方法を変えられるなら
どこのでもいいような気がする。
>請求合計金額が合わない
設計がかなり悪いんだろうね。 業務フローとかわかってる人が作らないと、どっかチグハグなものにはなりがちなんだと思う
既製のソフトやサービスでも所々使いにくい、ってのは出てくるんじゃない?
逆にそうした個別の要望に応えてカスタマイズしていける、ってのがファイルメーカーでやる強みな気がするけど >>276
>>277
なんせ知り合いのSEに丸投げだから、自分の好きなようにカスタマイズは難しい
問題発生→相談→改善という流れを何十回もやってる
が、問題点が次から次へと出てくるわ、外注なせいで対応が遅れがちになってしまうわで大変
スレチになってしまうからあまり長々とは話さないけど、第1候補はコスト面が魅力的なフリーウェイ販売管理を使おうと思ってる
オーベックやPCAはやはりコストがかかる
私自身もファイルメーカーに関して知識ないから、既存のものを使うっていう発想しかできなかった
ファイルメーカーに挫折して商品として完成しているクラウド会計ソフトに移行したという同じ境遇の人を探してこのスレに来たのだけど、私のレスのせいでスレの本題から逸れて邪魔になってしまうのは本意ではないので程々にしますね。
レスくれてありがとうございました。 >>276
>システムに合わせて事務処理の方法を変えられるなら
>どこのでもいいような気がする。
それが一番安上がりになるよね。
自社用にカスタマイズなんて話になると一気に敷居が高くなるので、パッケージに合わせて業務を変える。
みんななんでこれが出来ないんだろう? >>275
ファイルメーカーて作ってるけど
将来性とか細かいとこでこのままでいいのかな?という不安はあるよね それはどこでも同じ。
パッケージソフト側の都合や先行きなんて手向かえない。
会計や経理は仕事のノウハウそのものだから
明日から使えないでは会社として継続すら出来ない。
全員素人で済ませられるものかどうか考えた方がいいのでは? >>279
事務処理ってのは概ねその会社の営業がやってきた事が反映されるものだからね。
社内の事は自由に調整出来るけど、社外の事はそうも行かない。
例えば商品単価は顧客毎に違うのか?その顧客に売る場合は必ず同一単価なのか?
ある商品の原価はどの場合も同じなのか?納品先はいつも同じなのか?
担当者の成績は顧客ごとに決まるのか?そもそも固定の顧客はあるのか?
この辺を一つずつ紐解いて既存ソフトに当てはめて行くのは相当な業務知識が必要で、
更に事務処理側を変更するには社内への政治力が必要になるw
一番いいのは、会社の立ち上げ時点で既存ソフトを入れて、それに合わせた
営業活動をする事だと思う。 >>283
ファイルメーカーで下請けごとに金額かえたり
レコードをグループ化するのが大変
グループがないのは半かなり不便ですね、
分類でまとめて1レコードとしてあつかう、とかができない ちなみにEXCELから売上管理を移行中だけど3年ほどたっても完成してない
細かいとこまでこだわってしまうフォントやレイアウトに費やす時間がおおい 売上のテーブルと下請け業務発注テーブルと経費テーブル、仕入れテーブルは分けるべきですか?
フィールドやテーブルは増えて、正規化できてるようにも見えないけど
出納帳みたいに粗利だすならこうですか? FMからVBSやWSHで動かそうとするとなかなかだな >>286
おいおい 怖いこと言うなよ
手書きの帳面でもそれは分けるだろ >>284-286
一度、何かの教材に沿って一本作ってみた方がいいかもね。
あるいは自分で一から作るのではなく、サンプルを自分の思うように
変えるとか。 >>288
>>289
正規化はわかってるんですけど
FMはクエリもないし非連結フィールドもないので
テーブルをわけると計算がやりにくいんですよね
レコードのグループ化もないし
例えば売上カラ経費を引くとき、その計算結果をどちらかのテーブルに保持しなければなりませんが
どっちに保存すんだよって思います >>290
誰に文句言われる訳じゃなし、好きに作ったらいいんじゃない? ファイルメーカーは一般的なDBの理論は通用しないからね
バカみたいなフィールド数になる 売上テーブル
仕入テーブル
作って月ごとの売上求めるのにも自己リレーションとそれを集計する計算フィールド
月ごとの売上-仕入やるのも計算フィールドがいる
しかもその計算フィールドは売上か仕入のどちらかに置く必要があり
月ごと年ごとなど、それぞれ自己リレーションと計算フィールドがいる
集計フィールドつかえっていわれそうだけど
あれは使いにくいし、レイアウトに集計額配置するときなどに柔軟性もない
いちいちパートとか作らなきゃいけない
ましてや集計同士の計算なんて…… リレーションは必要最小限度にして、スクリプトなりで現在値などを
入れ込む仕様にするのも手。その分軽くもなる。 ■ このスレッドは過去ログ倉庫に格納されています