FileMakerAdvanceランタイムでデータ共有 (76ﾚｽ)
上下前次1-新
1(14): 2009/07/19(日)11:04 AAS
Advanceでランタイムを作って、それを各クライアントにインストール、
サーバーに見立てたPCにデータファイルを置いて、各ランタイムでデータ共有。
そんな「ケチケチファイル共有大作戦」を構想実験中。
2: 2009/07/19(日)11:33 AAS
【目的とメリット】
・サーバー＋クラ台数分というFMアプリ導入費を何とかしたい
例えば10台で運用するには、現状だと
pro(\34,200) * 10 + svr(\115,200) = \457,200
という費用が発生してしまう。
ランタイム運用なら開発側のAdv償却費程度（100%でも\52,200）
・OSとFMのバージョンアップによって発生するコストとライセンス追加問題を何とかしたい
省8
3(1): 2009/07/19(日)12:53 AAS
たとえば10台でとか書いてるけど、10台あっても誰か1人しか使うことが出来ないじゃん。
今誰が使ってるか確認しながらなんて実運用に耐えられるんだろうか？
まだインスタントwebとか使った方がストレスなさそう。
4: 2009/07/19(日)12:59 AAS
>>3
もうちょっとお待ちを。そのカラクリを書きますんで。
5: 2009/07/19(日)13:40 AAS
〜現状の基本概念〜
ランタイムはファイル共有操作は一切できないが、単独でファイルを開く事は可能であり、
それがOSのネットワーク共有フォルダにあってもローカル動揺に可能なので、その仕組みを利用する。
他のユーザーと同時にファイルを開けない。誰かが開いてる時は、他の誰かが開こうとしたら
エラー発生 →エラーの場合はN秒後に再実行 を繰り返す事で、共有は成り立つ。
･･･はずだが、ここにシステム依存なリスクが潜んでいる可能性が高く、最悪ファイルの破壊を想定しなければならない。
〜具体的な流れ〜
省20
6: 2009/07/19(日)13:41 AAS
【３】新規レコード作成･･･仮にT5テーブルにレコード追加したい場合
?file-Sを開く
?T5に新規レコード作成、同レコードRC=1
?file-Aにfile-S上書き
?T5の新規レコードに移動
?入力後【２−２】実行
【４】レコード削除･･･仮にT7R30を削除する場合
省4
7(1): 2009/07/19(日)13:59 AAS
つまり、file-Sを開いたら即file-Aの上書きコピーをし、file-Sを開いている時間を
最小限に留める事により、あたかもデータ共有しているかの様な操作体系が狙い。
〜以下、現状で問題視している事〜
A.各クラが特定レコードを編集するという事を明示的に行う必要があり、
例えばフィールド全置換えのような自由な編集を可能にするには工夫が必要。
B.クラ側には常にfile-Sの上書きが起るため、スクリプトはfile-A上では走らせられない。
つまり、クラ側にはfile-Aをコントロールする別のスクリプトファイルが必要。
省5
8(1): 2009/07/19(日)14:29 AAS
とりあえず乙。なるほどね。概略はわかった…ような気がする。
もっとシンプルにならんもんかね？AとBで差分抽出して交換するみたいな。
あと、
>?編集されたT3R15の１レコードのファイル（file-SR）を、Ｓローカルにエクスポート保存する。
>?file-Sを開く
>?file-SのT3R15にfile-SRを上書きインポート・RC消去
これこうする必要ある？直接Ａからピンポイントでインポートすればって思うが、何か問題ある？
9: 2009/07/19(日)14:31 AAS
いや待てｗ、そもそもサーバーのファイルってどこで開くの？鯖？蔵？
だめだ何かちょっと理解及んでないわｗ 出直してくる。
10: 2009/07/19(日)15:04 AAS
>>8
>これこうする必要ある？直接Ａからピンポイントでインポートすればって思うが、何か問題ある？
サーバ側のファイルをローカルで開いて操作するんだけど、直接クラからインポートとなると、クラが複数で
インポート元が１つじゃなくなるんで、サーバーファイルにクラ数分のスクリプト用意する必要があります。
更新レコードファイルを、各クラで統一した保存先とファイル名にすることで、サーバー側のスクリプトを
一元化できるわけです。
ただそれが原因で>7のＣっていう問題が発生するんですがね＾＾；
11(1): 2009/07/19(日)15:58 AAS
ちょっと参加してみます。宜しく。
正直本スレ見て無理じゃないかなと勘繰ってたんですが、
思ったよりイケソウナキガスルーです。
サンプルファイル的なものは無いでしょうか？
無ければ別にいいです。自分で作ってみますんで。
12(1): 2009/07/19(日)16:08 AAS
つインスタント Web機能
入力は出来ないけれどな。
13: 1 2009/07/19(日)16:15 AAS
>>12
検討はしてみたけど、UI的に無理かなぁと。制約多すぎて。
14: 1 2009/07/19(日)16:17 AAS
>>11
現時点でサンプルないっす。実働ファイルの改変で起こしたんで。
時間あったら作るけど、まだ未完成だし、ちと時間無いです。すまそ。
15(1): 2009/07/19(日)16:19 AAS
>1
>>ランタイム運用ならライセンスは無視できる（若干御幣覚悟ｗ）
せっかく良スレ期待なんだが、この一文は喧嘩腰杉じゃないか・・・まぁ覚悟はわかったガンガレ。
ところでこれバージョンどのあたり対象？なんとなく１０限定みたいな感じするが。
16: 1 2009/07/19(日)16:30 AAS
>>15
喧嘩腰ってわけじゃないですがね＾＾； FM社に喧嘩売ってる意味合いは否定しませんがｗ
バージョンについては、私の手元のは９です。確かに１０なら色々楽になりそうなんだけど・・・
スクリプト変数多用するんで、今回は８以降って感じで。
17(2): 2009/07/19(日)16:39 AAS
>?Ａローカルディスクに「名前を付けて保存（以下file-A）」にて上書きする
これ簡単に書いてるが、ネットワークトラフィックとか問題無いの？
毎回ウン百MBとかいちいち流せんだろ。ギガLAN前提としてもキツイと思うが。
小規模なら大丈夫だろうけど、うちじゃこの時点でアウト。
レコード修正時刻とかで改変レコード絞って抽出した方が賢いかと思う。
18(2): 2009/07/19(日)17:14 AAS
本スレの938です。
ざらっと読みましたが、結構工夫されてますね。
私の場合はノートの持ち出しと、帰社時の同期だけだったんで
事情が若干違いますが、似たような苦労をしました。
記憶を頼りに思い付いた点挙げてみます。
１．権限管理
これは共有で運用する以上、貴方のプランに限らず必要な事で、
省19
19(1): 2009/07/19(日)17:50 AAS
始めてカキコです。
うちの会社も実はバージョンアップ問題に直面しています。
数年前にバージョン５のサーバーと２０クライアントを導入したんですが、
現状残っているライセンスが１つだけで、そろそろ何とかしないといけない状況です。
追加ライセンスは当然５（６）は入手できないし、アプリケーションのバージョンアップは
８で試してみたけど、そのままやるとマトモに動かない事が判明しました。
それにそもそもOSがVistaだとバージョン６はサポート外です。orz
省8
20(1): 2009/07/19(日)18:10 AAS
この方法ってFM社視点だと営業妨害になんねーの？
ここじゃなくて他で非公開でｺｿｰﾘやる方がよくね？
21: 2009/07/19(日)18:14 AAS
>>17
同意。ネットワーク管理者にはおっかない仕様だな。
まぁ２０MBくらいが一応のラインってとこかな。
逆にその程度の操作ならFMサーバーとPro使うよりもサクサクが期待できるのか？
蔵がUMPCとかだと意外に戦えるかもしれん
22: 2009/07/19(日)18:21 AAS
今ちょっと試してみたが、案外大丈夫だな。50MBくらいでもGbイーサなら楽勝だった。
期待していいのか？
ちなみにUMPCだとローカルディスクがもっさりで駄目ぽだ。無線だと尚更厳しそうだ。
23(1): 2009/07/19(日)18:24 AAS
連投ですまんが、>1はどの程度の規模でやってるのか教えてくれ。
色々難点がありそうだけど試す価値はありそうだ。
24(1): 2009/07/19(日)18:29 AAS
>>18
>> 各クライアントはレコード変更する毎に毎回更新ファイルを吐き出し、
>> サーバーは定期的にそのファイルを拾い集めるという考え方です。
これ逆に難しくない？
同時に同じ人が同じレコード編集しようとした時、回避できないんじゃないかな？
25: 24 2009/07/19(日)18:31 AAS
訂正。
×同時に同じ人が同じレコード〜
○同時に別の人が同じレコード〜 ﾔｯﾁﾏｯﾀ
26: 1 2009/07/19(日)21:22 AAS
>>17
最初は変更レコードの抽出でスクリプト作ったけど、テーブル数が多いとチェックだけで
結構な時間要するんで、結果的にファイルごと読み込む方が速かったんです。
ファイルサイズは30MB程度ですが、読み込み時間は現状で1.5秒前後。我慢できる時間です。
でももっと大きくなると確かに無理があるかもしれませんねー。
ただ、同程度のファイルをFMサーバー無しの共有で運用するよりは、遥かに体感速度が速いです。
FMサーバー有りの場合はわかりませんが。
省6
27: 2009/07/19(日)21:32 AAS
>>18
ご助言ありがとうございます。
>１．権限管理
これは以前から導入されてはいるんですが、徹底すると逆にユーザーの制約が生まれて、
管理職の人から不満が出たりしたんです。で、結局緩めてしまいました。
これを徹底できたら確かに様々な点でリスクを減らせるポイントがありそうですね。
>２．ファイル更新時刻管理
省6
28: 2009/07/19(日)21:37 AAS
>>20
ｺｿｰﾘだと情報の共有が不自由かなと。てか、もう立てちゃったんで許してくださいｗ
営業妨害・・・かどうかはまだ結果が出ないことにはｗ
>>23
一応テーブル数21、最大レコード数は多いテーブルで約6万レコード、
フィールド数は多いテーブルで17、但しデータフィールドのみ。
ファイルサイズは現状31MBって感じです。
29(1): 2009/07/19(日)21:47 AAS
やっと整理した。
追っかけるの大変だ。
＞1はコテ酉付けてくれると幾分読みやすくなるんだがどう？
30: 1 2009/07/19(日)22:03 AAS
>>29
コテ酉・・・読めないけど、これ（１）でいい？
31(3): 2009/07/19(日)22:30 AAS
なんとなくサンプル的に作ってみました。
サーバとの受け渡しスクリプトは確かに１つですね、逆にそうしないと、複雑になりそうでした。
ちょっと今引っかかってるのが、
B.クラ側には常にfile-Sの上書きが起るため、スクリプトはfile-A上では走らせられない。
つまり、クラ側にはfile-Aをコントロールする別のスクリプトファイルが必要。
ここなんですが、操作してるＡから別ファイル（Ｃ）のスクリプトを起動して、Ｃスクリプト上でＡを閉じるって操作、どうしても無理なんです。
何か方法ありますか？それとも考え方が間違ってるのかな？
32: 2009/07/19(日)22:40 AAS
あと、Ａファイルを操作してて、レコード編集に入る時にＳから上書きって操作、本当に必要ですか？
これ結構無駄な気がしてならないんですが(´･ω･`)
サンプルで操作する分には、この上書きが何度されても、サイズ的に気にならないけど、
サイズ大きいファイルだと、こう何度も何度も上書きって、何か問題ありそうな気がしますが…。
せめて編集終了後だけにするなら、回数半分に減ると思うんです。
33: 2009/07/20(月)00:59 AAS
>1 おつです。
これ昔ちょっとやってみようって思った事だけど、時間に追われて結局断念したやつです。
どこで断念したのか曖昧だけど、Aさんが編集中にBさんが編集したら正解はどっち？みたいな感じだったかな。
フラグフィールドってのが当時思いついてたらちゃんと形にできてたかも。
とりあえず参考にさせていただきます。
>31
アツカマシイけど、そのサンプル晒してもらえませんか？自分でもちょっとやってみたいんで是非。
34(2): 2009/07/20(月)10:52 AAS
ぬぅ・・・自力では無理かやっぱ・・・これ凄いエゲツナイほどステップ多くならん？
あとローカルでせっかく細かい検索条件やらして絞り込んでも、上書きで乙だわな。
スレ主よ、もうちっと細部晒すか、サンプル出してくれ。頼むわ。
なんか物凄く無駄足踏んでるような気がする。
35(1): 2009/07/20(月)12:33 AAS
>34
同じく行き詰まりまくり。なんか本当にできるのか怪しくなってきた orz
>1氏は今日はお休み？
>31さん読んでたら進捗とかどないで？
36: 1 2009/07/21(火)08:28 AAS
あーすいません、昨日は完全休日で何もしませんでしたｗ
てか。。。もう作り始めた人いたんだぁ＾＾；恐縮っす。
やっぱちょっとサンプルみたいなの作ってみます。
ただランタイムで提供となるとサイズ大きいかな。
FMのまま出しても複数台でのチェックできそうでしょうか？
>>31
この時点の情報だけで良く作れますね〜すごいです。
省7
37: 2009/07/21(火)08:39 AAS
>>34-35
>ローカルでせっかく細かい検索条件やらして絞り込んでも、上書きで乙だわな
うっ・・・おっしゃるとーりでございます orz
ローカルでの最終検索条件を引き継いだり、色々思案したけど、どうもうまく行かない。
これも付いて回る大問題。インポートのが色んな意味で安定しそうっす。
インポートのが巧く動きそうなら、上書きは断念な方向になりはじめてますｗ
38: 1 2009/07/23(木)13:21 AAS
ただいまインポートエクスポートスタイルでサンプル作成中。
レコード削除の同期が大変ですねー。ファイル上書きなら全く問題にならなかったけど。
削除済みリストのグローバルフィールドを毎回覗く形で何とかなりそうだけど、
スクリプトが煩雑になりそうな悪寒。
まぁとりあえず今日中に最初のやつアップしてみます。
39: 1 2009/07/23(木)13:27 AAS
補足。
思案の挙句、起動時のみサーバーファイルを上書き読み込み、
操作中の更新はインポートという形に落ち着きそうです。
削除対応は今回はスルーかもです。
ただ、操作中に削除済みレコード操作しようとする時は回避できてます。
あと起動時の上書き操作は任意のタイミングでできるのでほぼ問題ないはずです。
では。
40(1): 2009/07/24(金)00:45 AAS
とりあえずサンプルとして、郵便番号の１テーブルで作ってみました。
外部ﾘﾝｸ[zip]:karintou.mine.nu
DLパス：fmrt
今回はランタイムではなく、ファイルメーカーのファイルです。
バージョンは９以降でお願いします。（８で正しく動作するかわかりません）
サーバー用のファイルはネットワーク先にも置けます。
複数人で運用可能です。
省2
41(1): 2009/07/24(金)16:43 AAS
＞４０ おつ。まずあぷろだ判りにくすぎｗ変えたほうがいい。
外部ﾘﾝｸ:www1.axfc.net こっちお勧め。
で、ざっくり感想言うと、速度はネットの共有フォルダ程度なら何とかなりそうだ、と感じた。
１２万レコードでこの程度の速度出るなら実用範囲だと思う。
しかもやってみたらランタイムでも実際動くんだな。カスタマイズやメンテでFM必要にはなるが。
ただ、途中までローカルファイル上書きの設計で進めて頓挫したこっちの身にもなってくれｗ
このインポート式は完全に正攻法＆じゃないか。これで済むなら最初から上書き計画しなかったのに。
省11
42(1): 2009/07/24(金)21:25 AAS
>>41
早速の試用レポ感謝です。
本当は解説をしておこうと思ってたんだけど、昨日は力尽きてｗ。解説より先にレスします。
>まずあぷろだ判りにくすぎｗ
すいません＾＾；今回は適当にググって済ませました。次回はお勧めのとこでうｐします。
>速度はネットの共有フォルダ程度なら何とかなりそうだ
そうですね。正直インポート型にすると先ず実用にならないって思ってたんだけど、
省13
43: 2009/07/24(金)21:25 AAS
>更新レコードのインポート方法ちょっとエラー対策不足。
うーんファイル上書き型の時はもっと手抜きだったんですが＾＾；
もう少し開発進んだら検討してみます。
>ローカルで大量レコード表示状態でソートかかってるともたつくが、
>これはウィンドウ処理のせい。工夫で回避できそう。
その通りです。既に承知はしてます。ご理解が早くて怖いｗ
>テーブル増えるとその分スクリプトも増える悪寒。
省6
44: 1 2009/07/24(金)21:29 AAS
解説しようと思ったけど、長くなりそうなんで割愛します＾＾；
今回はとりあえず弄ってもらって、質問や意見等のレスだけにしたいと思います。
どうかご容赦を。
45(1): 2009/07/25(土)00:08 AAS
サンプル拝見しました。
構造とかは今一理解に及んでないですが、とにかく共有はできるんですね。
無理が無いのなら、会社のシステムで、この仕組みを応用してみようと思います。
そこでいくつか質問させて頂きます。
１．複数クライアントで使う場合、どのようにすればできるんでしょうか？
複数台分のsrvファイルの同期方法がわかりません。
２．リスト表示や一覧表モードで、レコード編集する事はできないでしょうか？
省4
46: 2009/07/25(土)10:48 AAS
>>45
>１．複数クライアントで使う場合、どのようにすればできるんでしょうか？
複数台分のsrvファイルの同期方法がわかりません。
?最初にインストールしたクライアントでsrvを作り、どこかの共有フォルダに移動する
?クライアントの「〒user1」ファイルのスクリプト「サーバー処理」の手直しをする(ReadMe参照）
?次にインストールしたいクライアントに、最初のクライアントのフォルダをコピーをする
・・・つまりsrvファイルは全体で１つです。ご注意ください。
省15
47(1): 2009/07/25(土)11:11 AAS
>>42
＞アクティブテーブルのみに更新を絞っても運用上大した問題無さそうかなってことで
全力否定！リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。
サンプルのは計算関係全くスルーだから問題なけど、通常使用ではそんなケースの方が少ない。
関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
・・・多少で済むかどうかはまだわからんが。
ところで
省5
48: 2009/07/25(土)11:28 AAS
>>47
>全力否定！リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。
じつは今見積書のサンプルに取り掛かってるんだけど、そうかも？と感じ始めてたとこですｗ
レコード編集後には全体の更新入るんで、別に良いかな？と思ってたけど、印刷とか絡むと駄目ですねー。
ちょっと甘かったかなぁ・・・難儀な課題になりそう orz
>関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
何とかしてください！ｗ
49(1): 2009/07/25(土)12:36 AAS
これ本当に共有になってる？
同時進行でデータ更新されてないように見えるんだけど…どっか間違ってるのかな？
50(1): 2009/07/26(日)10:50 AAS
>40のをベースに、今複数テーブルのを作成中。
srv側のスクリプトで、1レコード検索してIDとUSER（編集者？）埋め込むとこがちと厄介。
テーブル毎に検索用のレイアウトを用意するか、スクリプトを並べるか･･･どっちもなんかねｗ
現状そこだけサブスクリプトとして切離して回す方法で進めてる。あんまスマートとは言えんけど。
それにしてもParameter便利だわ。GJ。ただセパレータをセミコロン1文字だと若干不安だから、3つにしてみたYO。
51: 2009/07/26(日)12:47 AAS
>主氏
あと、srv側のアドレスをどっかのフィールドかスクリプト変数で指定する形のがいいと思う。
まだ実験段階だから、スクリプト修正が余計に苦痛だし。
おヌヌメな方法は、起動スクリプトで$$変数指定。
実働状態になったらまた別かもしれんけど。
52: 50 2009/07/26(日)15:06 AAS
IDとUSER埋め込みに加えて、インポートもだな。うーん。
これは主の次のサンプル待ちかな。。。
>49
一応なってると思うよ。２台でやってみたが、ちゃんと同期ってる。
ただ時々怪しい時もあったｗ
53(1): 2009/07/26(日)18:23 AAS
Webのcgiとかと同じ発想だね
となるとファイルロックがあれば安心なんだけど
54(1): 2009/07/27(月)08:50 AAS
>>53
あー原理が近いね。
このサンプル見る限り、exp.fp7ってのが書き込みログに当たるのかな。
Aさんがexpを書き出す
↓ （もしこの間にBさんがexp書き出したら）
srvでexpを取り込む
（Aさんのexpが蹴られるかもしんない）
省2
55: 54 2009/07/27(月)09:13 AAS
・・・と思いきや、上手く逃げてるみたい。
書き込みにしろ読み込みにしろ、srvファイルのopenがトリガーになってるから、
srvが他人に開かれてる間は他者の読み書きが待機させられるように組まれてる。
56: 2009/07/27(月)10:47 AAS
＞50
＞srv側のスクリプトで、1レコード検索してIDとUSER（編集者？）埋め込むとこがちと厄介。
＞現状そこだけサブスクリプトとして切離して回す方法で進めてる。
現状ここはそれがベストじゃね？
俺は専用レイアウトでゴリ押しにしたんだがｗ テーブル数少なければ大して邪魔じゃないしな。
テーブル名無しで特定フィールド名に書き込むフィールド移動かフィールド設定あれば解決なんだがな。
57: 2009/07/29(水)09:30 AAS
>1
放置かよー
まぁ既に個別構築モードとも思えるが。
次サンプルは見ておきたい。
58: 2009/08/09(日)12:17 AAS
ageage
59: 2009/08/24(月)15:21 AAS
あげ
60: 2010/08/05(木)12:26 AAS
我々は1年待ったのだ！
61: CADソフト専門店 [soft@jp-cad.com] 2011/04/08(金)17:08 AAS
Filemaker 激安
詳しくは ホームページ: 外部ﾘﾝｸ:www.jp-cad.comをご覧ください。
62: 2012/08/20(月)19:45 AAS
age
63: あぼーん [あぼーん] AAS
あぼーん
64: 2013/10/22(火)19:49 AAS
FileMakerAdvanceランタイムでデータ共有
65: 2013/11/24(日)20:55 AAS
千葉県松戸市六高台2-78-3
66: 2014/10/30(木)08:52 AAS
保存アゲ
67: 2015/01/29(木)10:14 AAS
お世話になります。
私、責任者の加茂と申します。以後、宜しくお願い致します。
画像ﾘﾝｸ[jpg]:www.apamanshop.com
浪速建設様の見解と致しましては、メールによる対応に関しましては
受付しないということで、当初より返信を行っていないようで、今後につい
てもメールや書面での対応は致しかねるというお答えでした。
省10
68: 2015/05/17(日)22:43 AAS
14良いね
69: 2016/01/19(火)16:18 AAS
どうですかお客さん
70: 2016/01/24(日)09:18 AAS
http: // tests_am_pm_fc2 .blog .fc2 .com/
password watashinodennwabangou
f c 2 0 0 0 no blog desu
f c 2 8 8 8 8 8 8 8 8
71: 2016/05/17(火)22:38 AAS
15良いね
72: 2017/08/02(水)14:20 AAS
FileMaker Server 12の引っ越しを考えているんだけど、なんかいいサイトありませんか？
73: 2017/12/28(木)12:50 AAS
誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『加藤のセセエイウノノ』 というサイトで見ることができるらしいです。
グーグル検索⇒『加藤のセセエイウノノ』
JZOKB1998Z
74: 2019/08/08(木)02:29 AAS
社名をClarisに変更するとメールが来てた
以前もクラリス社だった事なかったっけ？
75: 2023/08/26(土)20:49 AAS
こりゃｗまた（ёдё）えぇらいこっちゃ②=３
76: 2023/09/30(土)20:36 AAS
文化祭でファラリスの雄牛って楽器の担当になった
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s