FileMakerAdvanceランタイムでデータ共有 本スレの938です。 ざらっと読みましたが、結構工夫されてますね。 私の場合はノートの持ち出しと、帰社時の同期だけだったんで 事情が若干違いますが、似たような苦労をしました。 記憶を頼りに思い付いた点挙げてみます。 1.権限管理 これは共有で運用する以上、貴方のプランに限らず必要な事で、 基本と言えば基本ですが、徹底するとファイル更新が楽にできます。 17さんの言われる「編集済みレコード抽出」を避けて、ファイルごと コピーを繰り返す設計をした理由は、私が想像するにはおそらく 更新スクリプトの複雑化を避けるって事だと見てますが (違ってたらごめんなさい)、レコード編集権限、削除権限を徹底すれば 案外すんなりできるはずです。ご検討してみてください。 2.ファイル更新時刻管理 Aさんがファイル変更できる時間帯、Bさんの時間帯、という具合に 何らかのルールを設けると、バッティングブレークはかなり避けられます。 フラッグファイルという方法も非常に面白いのですが、そのフラッグファイル そのものを壊す事も考えられるので、完全とは言えないように感じます。 3.更新作業をサーバーにさせる 各クライアントはレコード変更する毎に毎回更新ファイルを吐き出し、 サーバーは定期的にそのファイルを拾い集めるという考え方です。 サーバーもファイルメーカー或いはランタイムが動作しているのが前提と なりますが、サーバーのファイルをあえてクライアントに触らせない手法です。 ただクライアントが増えたり減ったりする度にスクリプト書き直す必要があったり、 正直デメリットも無視できませんが。 今回はこの辺で。
19 :
名無しさん@そうだ選挙にいこう :2009/07/19(日) 17:50:30
始めてカキコです。 うちの会社も実はバージョンアップ問題に直面しています。 数年前にバージョン5のサーバーと20クライアントを導入したんですが、 現状残っているライセンスが1つだけで、そろそろ何とかしないといけない状況です。 追加ライセンスは当然5(6)は入手できないし、アプリケーションのバージョンアップは 8で試してみたけど、そのままやるとマトモに動かない事が判明しました。 それにそもそもOSがVistaだとバージョン6はサポート外です。orz 考えられる方法は、相当な時間とお金をかけて全てバージョンアップを断行するか、 もっとお金をかけて?DBマネージメントを他所に依頼するか、という状況です。 実際やっていることは大したことではなく、社員各自の日報やタイムカードの連携といった程度なんですが、 それでも各チーム毎に入力するようになってるため、現状のシステムは非常に好評ではあります。 こちらの内容を見た瞬間、「これだ!」と感じた次第です。 他の方のご指摘通り危険もあるかもしれませんが、私程度でも実現できるのであれば、 会社的にも大幅なコスト削減となり、私としても評価が上がってry) なので挑戦してみたいです。 今後ともよろしくお願いします。
この方法ってFM社視点だと営業妨害になんねーの? ここじゃなくて他で非公開でコソーリやる方がよくね?
>>17 同意。ネットワーク管理者にはおっかない仕様だな。
まぁ20MBくらいが一応のラインってとこかな。
逆にその程度の操作ならFMサーバーとPro使うよりもサクサクが期待できるのか?
蔵がUMPCとかだと意外に戦えるかもしれん
今ちょっと試してみたが、案外大丈夫だな。50MBくらいでもGbイーサなら楽勝だった。 期待していいのか? ちなみにUMPCだとローカルディスクがもっさりで駄目ぽだ。無線だと尚更厳しそうだ。
連投ですまんが、>1はどの程度の規模でやってるのか教えてくれ。 色々難点がありそうだけど試す価値はありそうだ。
>>18 >> 各クライアントはレコード変更する毎に毎回更新ファイルを吐き出し、
>> サーバーは定期的にそのファイルを拾い集めるという考え方です。
これ逆に難しくない?
同時に同じ人が同じレコード編集しようとした時、回避できないんじゃないかな?
25 :
24 :2009/07/19(日) 18:31:14
訂正。 ×同時に同じ人が同じレコード〜 ○同時に別の人が同じレコード〜 ヤッチマッタ
26 :
1 :2009/07/19(日) 21:22:37
>>17 最初は変更レコードの抽出でスクリプト作ったけど、テーブル数が多いとチェックだけで
結構な時間要するんで、結果的にファイルごと読み込む方が速かったんです。
ファイルサイズは30MB程度ですが、読み込み時間は現状で1.5秒前後。我慢できる時間です。
でももっと大きくなると確かに無理があるかもしれませんねー。
ただ、同程度のファイルをFMサーバー無しの共有で運用するよりは、遥かに体感速度が速いです。
FMサーバー有りの場合はわかりませんが。
>>19 大変ですねー。バージョン5〜6あたりが今一番そういう問題を宿してるような気がします。
私も6から7に移る時相当苦労しました。てか結局ほとんど作り直したんですがw
そもそもファイルシステム違いすぎて無理がありましたよね。
6→7の時のような大幅なシステム変更は今後もう無いかもしれませんが、
とりあえず今回のチャレンジが多少なりともお力になれたら幸いです。
>>18 ご助言ありがとうございます。
>1.権限管理
これは以前から導入されてはいるんですが、徹底すると逆にユーザーの制約が生まれて、
管理職の人から不満が出たりしたんです。で、結局緩めてしまいました。
これを徹底できたら確かに様々な点でリスクを減らせるポイントがありそうですね。
>2.ファイル更新時刻管理
これは目からウロコです。ただタイムリーな更新という観点だと、何か難しい面がありそうな・・・。
ちょっと研究してみます。
>3.更新作業をサーバーにさせる
これも実は検討はしたんですが、考え方がまったく逆向きになりますよねー^^;。
出来そうではあるけど、ちょっと勇気が出ないというか、道のりが長そうと言うか。
もう少し具体的な部分やコツなどを教えて頂けたら助かります。
>>20 コソーリだと情報の共有が不自由かなと。てか、もう立てちゃったんで許してくださいw
営業妨害・・・かどうかはまだ結果が出ないことにはw
>>23 一応テーブル数21、最大レコード数は多いテーブルで約6万レコード、
フィールド数は多いテーブルで17、但しデータフィールドのみ。
ファイルサイズは現状31MBって感じです。
やっと整理した。 追っかけるの大変だ。 >1はコテ酉付けてくれると幾分読みやすくなるんだがどう?
30 :
1 :2009/07/19(日) 22:03:50
>>29 コテ酉・・・読めないけど、これ(1)でいい?
なんとなくサンプル的に作ってみました。 サーバとの受け渡しスクリプトは確かに1つですね、逆にそうしないと、複雑になりそうでした。 ちょっと今引っかかってるのが、 B.クラ側には常にfile-Sの上書きが起るため、スクリプトはfile-A上では走らせられない。 つまり、クラ側にはfile-Aをコントロールする別のスクリプトファイルが必要。 ここなんですが、操作してるAから別ファイル(C)のスクリプトを起動して、Cスクリプト上でAを閉じるって操作、どうしても無理なんです。 何か方法ありますか?それとも考え方が間違ってるのかな?
あと、Aファイルを操作してて、レコード編集に入る時にSから上書きって操作、本当に必要ですか? これ結構無駄な気がしてならないんですが(´・ω・`) サンプルで操作する分には、この上書きが何度されても、サイズ的に気にならないけど、 サイズ大きいファイルだと、こう何度も何度も上書きって、何か問題ありそうな気がしますが…。 せめて編集終了後だけにするなら、回数半分に減ると思うんです。
33 :
名無しさん@そうだ選挙にいこう :2009/07/20(月) 00:59:58
>1 おつです。 これ昔ちょっとやってみようって思った事だけど、時間に追われて結局断念したやつです。 どこで断念したのか曖昧だけど、Aさんが編集中にBさんが編集したら正解はどっち?みたいな感じだったかな。 フラグフィールドってのが当時思いついてたらちゃんと形にできてたかも。 とりあえず参考にさせていただきます。 >31 アツカマシイけど、そのサンプル晒してもらえませんか?自分でもちょっとやってみたいんで是非。
ぬぅ・・・自力では無理かやっぱ・・・これ凄いエゲツナイほどステップ多くならん? あとローカルでせっかく細かい検索条件やらして絞り込んでも、上書きで乙だわな。 スレ主よ、もうちっと細部晒すか、サンプル出してくれ。頼むわ。 なんか物凄く無駄足踏んでるような気がする。
>34 同じく行き詰まりまくり。なんか本当にできるのか怪しくなってきた orz >1氏は今日はお休み? >31さん読んでたら進捗とかどないで?
36 :
1 :2009/07/21(火) 08:28:07
あーすいません、昨日は完全休日で何もしませんでしたw
てか。。。もう作り始めた人いたんだぁ^^;恐縮っす。
やっぱちょっとサンプルみたいなの作ってみます。
ただランタイムで提供となるとサイズ大きいかな。
FMのまま出しても複数台でのチェックできそうでしょうか?
>>31 この時点の情報だけで良く作れますね〜すごいです。
うちは基本の部分にどんだけ時間費やしたことやらw。
>操作してるAから別ファイル(C)のスクリプトを起動して、Cスクリプト上でAを閉じるって操作、どうしても無理
そこは何の工夫も無く大丈夫だなぁ。Aのスクリプトからサブスクリプト呼びしてる可能性あり。
>あと、Aファイルを操作してて、レコード編集に入る時にSから上書きって操作、本当に必要ですか?
これ必要ないっす。上書きじゃなくて1レコードインポートです。自分の書き方足りなかったかも^^;。
ただ確かにファイル丸ごと上書き連射は、ちょっと考え直そうかなと思案中。
狙い撃ちインポートだと、見ているテーブルだけに絞ったりとか、何らかの合理化が必要ですねー。
>>34-35 >ローカルでせっかく細かい検索条件やらして絞り込んでも、上書きで乙だわな
うっ・・・おっしゃるとーりでございます orz
ローカルでの最終検索条件を引き継いだり、色々思案したけど、どうもうまく行かない。
これも付いて回る大問題。インポートのが色んな意味で安定しそうっす。
インポートのが巧く動きそうなら、上書きは断念な方向になりはじめてますw
38 :
1 :2009/07/23(木) 13:21:18
ただいまインポートエクスポートスタイルでサンプル作成中。 レコード削除の同期が大変ですねー。ファイル上書きなら全く問題にならなかったけど。 削除済みリストのグローバルフィールドを毎回覗く形で何とかなりそうだけど、 スクリプトが煩雑になりそうな悪寒。 まぁとりあえず今日中に最初のやつアップしてみます。
39 :
1 :2009/07/23(木) 13:27:43
補足。 思案の挙句、起動時のみサーバーファイルを上書き読み込み、 操作中の更新はインポートという形に落ち着きそうです。 削除対応は今回はスルーかもです。 ただ、操作中に削除済みレコード操作しようとする時は回避できてます。 あと起動時の上書き操作は任意のタイミングでできるのでほぼ問題ないはずです。 では。
>40 おつ。まずあぷろだ判りにくすぎw変えたほうがいい。
http://www1.axfc.net/uploader/O/ こっちお勧め。
で、ざっくり感想言うと、速度はネットの共有フォルダ程度なら何とかなりそうだ、と感じた。
12万レコードでこの程度の速度出るなら実用範囲だと思う。
しかもやってみたらランタイムでも実際動くんだな。カスタマイズやメンテでFM必要にはなるが。
ただ、途中までローカルファイル上書きの設計で進めて頓挫したこっちの身にもなってくれw
このインポート式は完全に正攻法&じゃないか。これで済むなら最初から上書き計画しなかったのに。
とにかくあれこれ弄ってみるよ。
で、現時点での問題点を晒してみる。
・ローカルファイルで開発→サーバーファイルを作る これは荒業すぎかも。
・更新レコードのインポート方法ちょっとエラー対策不足。ネット運用前提ならもう少し万全にした方がいい。
・ローカルで大量レコード表示状態でソートかかってるともたつくが、これはウィンドウ処理のせい。工夫で回避できそう。
・テーブル増えるとその分スクリプトも増える悪寒。
まぁまだ問題も未知数だしグレードアップの余地もありそうだし、現時点ではこれ以上評価難しい。
あと本題とはズレるが、何しろカスタム関数のParameterに感動した。
最初は意味よくわからんかったが、よくよく見るとすごいよこれ。
このカスタム関数のおかげでスクリプトがこんだけスマートになってるのな。
これはありがたく頂戴させてもらう。
>>41 早速の試用レポ感謝です。
本当は解説をしておこうと思ってたんだけど、昨日は力尽きてw。解説より先にレスします。
>まずあぷろだ判りにくすぎw
すいません^^;今回は適当にググって済ませました。次回はお勧めのとこでうpします。
>速度はネットの共有フォルダ程度なら何とかなりそうだ
そうですね。正直インポート型にすると先ず実用にならないって思ってたんだけど、
予想外に動きが良かったんです。固有ID(今回の〒)で運用前提ではありますが。
>しかもやってみたらランタイムでも実際動くんだな。
これは大前提ですからw 次回はランタイム版でアップ予定です。サイズ怖いけどw
>途中までローカルファイル上書きの設計で進めて頓挫したこっちの身にもなってくれ
まことに申し訳ないとしか言い様が無いです^^;
やっぱ検索状態の維持が不可能ってのは完全にお手上げだったんで。
複数テーブルの更新だとさすがに時間かかるんだけど、アクティブテーブルのみに
更新を絞っても運用上大した問題無さそうかなってことで、そうしたらインポート時間は
かなり速いし、全体的にすっきりしたんで、多分もう完全にこっち(インポート型)にします。
>ローカルファイルで開発→サーバーファイルを作る これは荒業すぎかも
そうなんだけど、実用段階に行ったら多分同様手口wの逆向きになります。
メンテするファイルが複数になるよりは絶対手間が少なく済むはずなんで。
〜つづく〜
>更新レコードのインポート方法ちょっとエラー対策不足。 うーんファイル上書き型の時はもっと手抜きだったんですが^^; もう少し開発進んだら検討してみます。 >ローカルで大量レコード表示状態でソートかかってるともたつくが、 >これはウィンドウ処理のせい。工夫で回避できそう。 その通りです。既に承知はしてます。ご理解が早くて怖いw >テーブル増えるとその分スクリプトも増える悪寒。 もちろん。まぁ覚悟の上でw >カスタム関数のParameterに感動した これはバージョン8以降、どのシステムにも必ず組み込んでます。手前味噌だけど本当に便利。 ただ、変数名とかちゃんと把握して組まないと、エラー出ないんでデバッグが結構大変w。 他にも日付を数値入力するやつとかも結構便利なんで、そのうち公開してみます。 今後ともよろしくです。
44 :
1 :2009/07/24(金) 21:29:00
解説しようと思ったけど、長くなりそうなんで割愛します^^; 今回はとりあえず弄ってもらって、質問や意見等のレスだけにしたいと思います。 どうかご容赦を。
サンプル拝見しました。 構造とかは今一理解に及んでないですが、とにかく共有はできるんですね。 無理が無いのなら、会社のシステムで、この仕組みを応用してみようと思います。 そこでいくつか質問させて頂きます。 1.複数クライアントで使う場合、どのようにすればできるんでしょうか? 複数台分のsrvファイルの同期方法がわかりません。 2.リスト表示や一覧表モードで、レコード編集する事はできないでしょうか? 3.〒userファイルで設定を修正したら、srvファイルも同様に修正しなければならないんでしょうか? 4.Parameter関数というのは何なのでしょうか? 5.レコード編集後に、「保存?復帰?」という選択がされるのは何故でしょうか? 初歩的な質問かもしれませんが、よろしくお願いします。
>>45 >1.複数クライアントで使う場合、どのようにすればできるんでしょうか?
複数台分のsrvファイルの同期方法がわかりません。
@最初にインストールしたクライアントでsrvを作り、どこかの共有フォルダに移動する
Aクライアントの「〒user1」ファイルのスクリプト「サーバー処理」の手直しをする(ReadMe参照)
B次にインストールしたいクライアントに、最初のクライアントのフォルダをコピーをする
・・・つまりsrvファイルは全体で1つです。ご注意ください。
>2.リスト表示や一覧表モードで、レコード編集する事はできないでしょうか?
おそらくバージョン10になったら可能なんですが、現状無理しない設計してるんで^^;
ブラウズは基本的にリスト表示、編集はフッタエリアっていうスタイルになります。
>3.〒userファイルで設定を修正したら、srvファイルも同様に修正しなければならないんでしょうか?
そうやっても良いんですが、userで修正→user閉じる→srvを削除→userをコピー→srvにリネーム
の方が早くて安全です。
>4.Parameter関数というのは何なのでしょうか?
1テキストで複数の値を表現するカスタム関数です。
例えば、Aというフィールドに「x=10;n=たろう;t=16:30:00」という値が入ってたら、
Parameter( A ; "x" ) は「10」、Parameter( A ; "t" ) は「16:30:00」を返します。
ようはスクリプト引数を多層化する目的のものですが、使い方次第で色んな事ができます。
>5.レコード編集後に、「保存?復帰?」という選択がされるのは何故でしょうか?
これはあまり意味は無いんですが^^;、「レコードの復帰」を擬似的に行うものです。
まぁファイル同期を利用して「こんなこともできます」って感じで表現しただけですw
また何かあったらお伝えください^^
>>42 >アクティブテーブルのみに更新を絞っても運用上大した問題無さそうかなってことで
全力否定!リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。
サンプルのは計算関係全くスルーだから問題なけど、通常使用ではそんなケースの方が少ない。
関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
・・・多少で済むかどうかはまだわからんが。
ところで
>ローカルファイルで開発→サーバーファイルを作る これは荒業すぎかも
>そうなんだけど、実用段階に行ったら多分同様手口wの逆向きになります。
>メンテするファイルが複数になるよりは絶対手間が少なく済むはずなんで。
すまん、これ撤回。これ合理的だった。てかファイル上書きのと同じ思想だったのな。
新発想目白押しで理解が追い付かなんだわw
>>47 >全力否定!リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。
じつは今見積書のサンプルに取り掛かってるんだけど、そうかも?と感じ始めてたとこですw
レコード編集後には全体の更新入るんで、別に良いかな?と思ってたけど、印刷とか絡むと駄目ですねー。
ちょっと甘かったかなぁ・・・難儀な課題になりそう orz
>関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
何とかしてください!w
これ本当に共有になってる? 同時進行でデータ更新されてないように見えるんだけど…どっか間違ってるのかな?
>40のをベースに、今複数テーブルのを作成中。 srv側のスクリプトで、1レコード検索してIDとUSER(編集者?)埋め込むとこがちと厄介。 テーブル毎に検索用のレイアウトを用意するか、スクリプトを並べるか・・・どっちもなんかねw 現状そこだけサブスクリプトとして切離して回す方法で進めてる。あんまスマートとは言えんけど。 それにしてもParameter便利だわ。GJ。ただセパレータをセミコロン1文字だと若干不安だから、3つにしてみたYO。
>主氏 あと、srv側のアドレスをどっかのフィールドかスクリプト変数で指定する形のがいいと思う。 まだ実験段階だから、スクリプト修正が余計に苦痛だし。 おヌヌメな方法は、起動スクリプトで$$変数指定。 実働状態になったらまた別かもしれんけど。
52 :
50 :2009/07/26(日) 15:06:14
IDとUSER埋め込みに加えて、インポートもだな。うーん。 これは主の次のサンプル待ちかな。。。 >49 一応なってると思うよ。2台でやってみたが、ちゃんと同期ってる。 ただ時々怪しい時もあったw
53 :
名無しさん@そうだ選挙にいこう :2009/07/26(日) 18:23:03
Webのcgiとかと同じ発想だね となるとファイルロックがあれば安心なんだけど
>>53 あー原理が近いね。
このサンプル見る限り、exp.fp7ってのが書き込みログに当たるのかな。
Aさんがexpを書き出す
↓ (もしこの間にBさんがexp書き出したら)
srvでexpを取り込む
(Aさんのexpが蹴られるかもしんない)
蹴られたらタダじゃ済まないなw
確かにファイルロック的な何かが必要そうだ。
55 :
54 :2009/07/27(月) 09:13:07
・・・と思いきや、上手く逃げてるみたい。 書き込みにしろ読み込みにしろ、srvファイルのopenがトリガーになってるから、 srvが他人に開かれてる間は他者の読み書きが待機させられるように組まれてる。
>50 >srv側のスクリプトで、1レコード検索してIDとUSER(編集者?)埋め込むとこがちと厄介。 >現状そこだけサブスクリプトとして切離して回す方法で進めてる。 現状ここはそれがベストじゃね? 俺は専用レイアウトでゴリ押しにしたんだがw テーブル数少なければ大して邪魔じゃないしな。 テーブル名無しで特定フィールド名に書き込むフィールド移動かフィールド設定あれば解決なんだがな。
>1 放置かよー まぁ既に個別構築モードとも思えるが。 次サンプルは見ておきたい。
ageage
あげ
60 :
名無しさん@そうだ選挙にいこう :2010/08/05(木) 12:26:07
我々は1年待ったのだ!
age
あぼーん
FileMakerAdvanceランタイムでデータ共有
千葉県松戸市六高台2-78-3
66 :
名無しさん@そうだ選挙にいこう :2014/10/30(木) 08:52:30.02
保存アゲ
67 :
名無しさん@そうだ選挙にいこう :
2015/01/29(木) 10:14:04.24