X
FileMakerAdvanceランタイムでデータ共有
0001名無しさん＠そうだ選挙にいこう垢版2009/07/19(日) 11:04:32
Advanceでランタイムを作って、それを各クライアントにインストール、
サーバーに見立てたPCにデータファイルを置いて、各ランタイムでデータ共有。
そんな「ケチケチファイル共有大作戦」を構想実験中。
00261垢版2009/07/19(日) 21:22:37
>>17
最初は変更レコードの抽出でスクリプト作ったけど、テーブル数が多いとチェックだけで
結構な時間要するんで、結果的にファイルごと読み込む方が速かったんです。
ファイルサイズは30MB程度ですが、読み込み時間は現状で1.5秒前後。我慢できる時間です。
でももっと大きくなると確かに無理があるかもしれませんねー。
ただ、同程度のファイルをFMサーバー無しの共有で運用するよりは、遥かに体感速度が速いです。
FMサーバー有りの場合はわかりませんが。

>>19
大変ですねー。バージョン5～6あたりが今一番そういう問題を宿してるような気がします。
私も6から7に移る時相当苦労しました。てか結局ほとんど作り直したんですがｗ
そもそもファイルシステム違いすぎて無理がありましたよね。
6→7の時のような大幅なシステム変更は今後もう無いかもしれませんが、
とりあえず今回のチャレンジが多少なりともお力になれたら幸いです。
0027名無しさん＠そうだ選挙にいこう垢版2009/07/19(日) 21:32:03
>>18
ご助言ありがとうございます。

>１．権限管理
これは以前から導入されてはいるんですが、徹底すると逆にユーザーの制約が生まれて、
管理職の人から不満が出たりしたんです。で、結局緩めてしまいました。
これを徹底できたら確かに様々な点でリスクを減らせるポイントがありそうですね。

>２．ファイル更新時刻管理
これは目からウロコです。ただタイムリーな更新という観点だと、何か難しい面がありそうな･･･。
ちょっと研究してみます。

>３．更新作業をサーバーにさせる
これも実は検討はしたんですが、考え方がまったく逆向きになりますよねー＾＾；。
出来そうではあるけど、ちょっと勇気が出ないというか、道のりが長そうと言うか。
もう少し具体的な部分やコツなどを教えて頂けたら助かります。
0028名無しさん＠そうだ選挙にいこう垢版2009/07/19(日) 21:37:45
>>20
ｺｿｰﾘだと情報の共有が不自由かなと。てか、もう立てちゃったんで許してくださいｗ
営業妨害・・・かどうかはまだ結果が出ないことにはｗ

>>23
一応テーブル数21、最大レコード数は多いテーブルで約6万レコード、
フィールド数は多いテーブルで17、但しデータフィールドのみ。
ファイルサイズは現状31MBって感じです。
00301垢版2009/07/19(日) 22:03:50
>>29
コテ酉・・・読めないけど、これ（１）でいい？
0031名無しさん＠そうだ選挙にいこう垢版2009/07/19(日) 22:30:49
なんとなくサンプル的に作ってみました。
サーバとの受け渡しスクリプトは確かに１つですね、逆にそうしないと、複雑になりそうでした。

ちょっと今引っかかってるのが、

B.クラ側には常にfile-Sの上書きが起るため、スクリプトはfile-A上では走らせられない。
　つまり、クラ側にはfile-Aをコントロールする別のスクリプトファイルが必要。

ここなんですが、操作してるＡから別ファイル（Ｃ）のスクリプトを起動して、Ｃスクリプト上でＡを閉じるって操作、どうしても無理なんです。
何か方法ありますか？それとも考え方が間違ってるのかな？
0032名無しさん＠そうだ選挙にいこう垢版2009/07/19(日) 22:40:34
あと、Ａファイルを操作してて、レコード編集に入る時にＳから上書きって操作、本当に必要ですか？
これ結構無駄な気がしてならないんですが(´･ω･`)
サンプルで操作する分には、この上書きが何度されても、サイズ的に気にならないけど、
サイズ大きいファイルだと、こう何度も何度も上書きって、何か問題ありそうな気がしますが…。
せめて編集終了後だけにするなら、回数半分に減ると思うんです。
0033名無しさん＠そうだ選挙にいこう垢版2009/07/20(月) 00:59:58
>1　おつです。
これ昔ちょっとやってみようって思った事だけど、時間に追われて結局断念したやつです。
どこで断念したのか曖昧だけど、Aさんが編集中にBさんが編集したら正解はどっち？みたいな感じだったかな。
フラグフィールドってのが当時思いついてたらちゃんと形にできてたかも。
とりあえず参考にさせていただきます。

>31
アツカマシイけど、そのサンプル晒してもらえませんか？自分でもちょっとやってみたいんで是非。
0034名無しさん＠そうだ選挙にいこう垢版2009/07/20(月) 10:52:37
ぬぅ・・・自力では無理かやっぱ・・・これ凄いエゲツナイほどステップ多くならん？
あとローカルでせっかく細かい検索条件やらして絞り込んでも、上書きで乙だわな。
スレ主よ、もうちっと細部晒すか、サンプル出してくれ。頼むわ。
なんか物凄く無駄足踏んでるような気がする。
0035名無しさん＠そうだ選挙にいこう垢版2009/07/20(月) 12:33:32
>34
同じく行き詰まりまくり。なんか本当にできるのか怪しくなってきた　orz

>1氏は今日はお休み？
>31さん読んでたら進捗とかどないで？
00361垢版2009/07/21(火) 08:28:07
あーすいません、昨日は完全休日で何もしませんでしたｗ
てか。。。もう作り始めた人いたんだぁ＾＾；恐縮っす。

やっぱちょっとサンプルみたいなの作ってみます。
ただランタイムで提供となるとサイズ大きいかな。
FMのまま出しても複数台でのチェックできそうでしょうか？

>>31
この時点の情報だけで良く作れますね～すごいです。
うちは基本の部分にどんだけ時間費やしたことやらｗ。

>操作してるＡから別ファイル（Ｃ）のスクリプトを起動して、Ｃスクリプト上でＡを閉じるって操作、どうしても無理
そこは何の工夫も無く大丈夫だなぁ。Ａのスクリプトからサブスクリプト呼びしてる可能性あり。

>あと、Ａファイルを操作してて、レコード編集に入る時にＳから上書きって操作、本当に必要ですか？
これ必要ないっす。上書きじゃなくて１レコードインポートです。自分の書き方足りなかったかも＾＾；。
ただ確かにファイル丸ごと上書き連射は、ちょっと考え直そうかなと思案中。
狙い撃ちインポートだと、見ているテーブルだけに絞ったりとか、何らかの合理化が必要ですねー。
0037名無しさん＠そうだ選挙にいこう垢版2009/07/21(火) 08:39:25
>>34-35

>ローカルでせっかく細かい検索条件やらして絞り込んでも、上書きで乙だわな

うっ・・・おっしゃるとーりでございます　orz
ローカルでの最終検索条件を引き継いだり、色々思案したけど、どうもうまく行かない。
これも付いて回る大問題。インポートのが色んな意味で安定しそうっす。
インポートのが巧く動きそうなら、上書きは断念な方向になりはじめてますｗ
00381垢版2009/07/23(木) 13:21:18
ただいまインポートエクスポートスタイルでサンプル作成中。
レコード削除の同期が大変ですねー。ファイル上書きなら全く問題にならなかったけど。
削除済みリストのグローバルフィールドを毎回覗く形で何とかなりそうだけど、
スクリプトが煩雑になりそうな悪寒。
まぁとりあえず今日中に最初のやつアップしてみます。
00391垢版2009/07/23(木) 13:27:43
補足。
思案の挙句、起動時のみサーバーファイルを上書き読み込み、
操作中の更新はインポートという形に落ち着きそうです。
削除対応は今回はスルーかもです。
ただ、操作中に削除済みレコード操作しようとする時は回避できてます。
あと起動時の上書き操作は任意のタイミングでできるのでほぼ問題ないはずです。
では。
0040名無しさん＠そうだ選挙にいこう垢版2009/07/24(金) 00:45:25
とりあえずサンプルとして、郵便番号の１テーブルで作ってみました。
http://karintou.mine.nu/uploader/download/1248363644/attach/FMRT_test.zip
DLパス：fmrt

今回はランタイムではなく、ファイルメーカーのファイルです。
バージョンは９以降でお願いします。（８で正しく動作するかわかりません）
サーバー用のファイルはネットワーク先にも置けます。
複数人で運用可能です。

適当に弄ってみてください。
詳しい解説は明日以降に書く・・・つもりです。
0041名無しさん＠そうだ選挙にいこう垢版2009/07/24(金) 16:43:58
＞４０　おつ。まずあぷろだ判りにくすぎｗ変えたほうがいい。
http://www1.axfc.net/uploader/O/　こっちお勧め。

で、ざっくり感想言うと、速度はネットの共有フォルダ程度なら何とかなりそうだ、と感じた。
１２万レコードでこの程度の速度出るなら実用範囲だと思う。
しかもやってみたらランタイムでも実際動くんだな。カスタマイズやメンテでFM必要にはなるが。

ただ、途中までローカルファイル上書きの設計で進めて頓挫したこっちの身にもなってくれｗ
このインポート式は完全に正攻法＆じゃないか。これで済むなら最初から上書き計画しなかったのに。
とにかくあれこれ弄ってみるよ。

で、現時点での問題点を晒してみる。

・ローカルファイルで開発→サーバーファイルを作る　これは荒業すぎかも。
・更新レコードのインポート方法ちょっとエラー対策不足。ネット運用前提ならもう少し万全にした方がいい。
・ローカルで大量レコード表示状態でソートかかってるともたつくが、これはウィンドウ処理のせい。工夫で回避できそう。
・テーブル増えるとその分スクリプトも増える悪寒。

まぁまだ問題も未知数だしグレードアップの余地もありそうだし、現時点ではこれ以上評価難しい。

あと本題とはズレるが、何しろカスタム関数のParameterに感動した。
最初は意味よくわからんかったが、よくよく見るとすごいよこれ。
このカスタム関数のおかげでスクリプトがこんだけスマートになってるのな。
これはありがたく頂戴させてもらう。
0042名無しさん＠そうだ選挙にいこう垢版2009/07/24(金) 21:25:02
>>41
早速の試用レポ感謝です。
本当は解説をしておこうと思ってたんだけど、昨日は力尽きてｗ。解説より先にレスします。

>まずあぷろだ判りにくすぎｗ
すいません＾＾；今回は適当にググって済ませました。次回はお勧めのとこでうｐします。

>速度はネットの共有フォルダ程度なら何とかなりそうだ
そうですね。正直インポート型にすると先ず実用にならないって思ってたんだけど、
予想外に動きが良かったんです。固有ID（今回の〒）で運用前提ではありますが。

>しかもやってみたらランタイムでも実際動くんだな。
これは大前提ですからｗ　次回はランタイム版でアップ予定です。サイズ怖いけどｗ

>途中までローカルファイル上書きの設計で進めて頓挫したこっちの身にもなってくれ
まことに申し訳ないとしか言い様が無いです＾＾；
やっぱ検索状態の維持が不可能ってのは完全にお手上げだったんで。
複数テーブルの更新だとさすがに時間かかるんだけど、アクティブテーブルのみに
更新を絞っても運用上大した問題無さそうかなってことで、そうしたらインポート時間は
かなり速いし、全体的にすっきりしたんで、多分もう完全にこっち（インポート型）にします。

>ローカルファイルで開発→サーバーファイルを作る　これは荒業すぎかも
そうなんだけど、実用段階に行ったら多分同様手口ｗの逆向きになります。
メンテするファイルが複数になるよりは絶対手間が少なく済むはずなんで。

～つづく～
0043名無しさん＠そうだ選挙にいこう垢版2009/07/24(金) 21:25:23
>更新レコードのインポート方法ちょっとエラー対策不足。
うーんファイル上書き型の時はもっと手抜きだったんですが＾＾；
もう少し開発進んだら検討してみます。

>ローカルで大量レコード表示状態でソートかかってるともたつくが、
>これはウィンドウ処理のせい。工夫で回避できそう。
その通りです。既に承知はしてます。ご理解が早くて怖いｗ

>テーブル増えるとその分スクリプトも増える悪寒。
もちろん。まぁ覚悟の上でｗ

>カスタム関数のParameterに感動した
これはバージョン８以降、どのシステムにも必ず組み込んでます。手前味噌だけど本当に便利。
ただ、変数名とかちゃんと把握して組まないと、エラー出ないんでデバッグが結構大変ｗ。
他にも日付を数値入力するやつとかも結構便利なんで、そのうち公開してみます。

今後ともよろしくです。
00441垢版2009/07/24(金) 21:29:00
解説しようと思ったけど、長くなりそうなんで割愛します＾＾；
今回はとりあえず弄ってもらって、質問や意見等のレスだけにしたいと思います。
どうかご容赦を。
0045名無しさん＠そうだ選挙にいこう垢版2009/07/25(土) 00:08:26
サンプル拝見しました。
構造とかは今一理解に及んでないですが、とにかく共有はできるんですね。
無理が無いのなら、会社のシステムで、この仕組みを応用してみようと思います。


そこでいくつか質問させて頂きます。

１．複数クライアントで使う場合、どのようにすればできるんでしょうか？
　　複数台分のsrvファイルの同期方法がわかりません。

２．リスト表示や一覧表モードで、レコード編集する事はできないでしょうか？

３．〒userファイルで設定を修正したら、srvファイルも同様に修正しなければならないんでしょうか？

４．Parameter関数というのは何なのでしょうか？

５．レコード編集後に、「保存？復帰？」という選択がされるのは何故でしょうか？


初歩的な質問かもしれませんが、よろしくお願いします。
0046名無しさん＠そうだ選挙にいこう垢版2009/07/25(土) 10:48:17
>>45
>１．複数クライアントで使う場合、どのようにすればできるんでしょうか？
　　複数台分のsrvファイルの同期方法がわかりません。
①最初にインストールしたクライアントでsrvを作り、どこかの共有フォルダに移動する
②クライアントの「〒user1」ファイルのスクリプト「サーバー処理」の手直しをする(ReadMe参照）
③次にインストールしたいクライアントに、最初のクライアントのフォルダをコピーをする
・・・つまりsrvファイルは全体で１つです。ご注意ください。

>２．リスト表示や一覧表モードで、レコード編集する事はできないでしょうか？
おそらくバージョン１０になったら可能なんですが、現状無理しない設計してるんで＾＾；
ブラウズは基本的にリスト表示、編集はフッタエリアっていうスタイルになります。

>３．〒userファイルで設定を修正したら、srvファイルも同様に修正しなければならないんでしょうか？
そうやっても良いんですが、userで修正→user閉じる→srvを削除→userをコピー→srvにリネーム
の方が早くて安全です。

>４．Parameter関数というのは何なのでしょうか？
１テキストで複数の値を表現するカスタム関数です。
例えば、Aというフィールドに「x=10;n=たろう;t=16:30:00」という値が入ってたら、
Parameter（ A ; "x" )　は「10」、Parameter（ A ; "t" )　は「16:30:00」を返します。
ようはスクリプト引数を多層化する目的のものですが、使い方次第で色んな事ができます。

>５．レコード編集後に、「保存？復帰？」という選択がされるのは何故でしょうか？
これはあまり意味は無いんですが＾＾；、「レコードの復帰」を擬似的に行うものです。
まぁファイル同期を利用して「こんなこともできます」って感じで表現しただけですｗ

また何かあったらお伝えください＾＾
0047名無しさん＠そうだ選挙にいこう垢版2009/07/25(土) 11:11:25
>>42
＞アクティブテーブルのみに更新を絞っても運用上大した問題無さそうかなってことで
全力否定！リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。
サンプルのは計算関係全くスルーだから問題なけど、通常使用ではそんなケースの方が少ない。
関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
・・・多少で済むかどうかはまだわからんが。

ところで

>ローカルファイルで開発→サーバーファイルを作る　これは荒業すぎかも
＞そうなんだけど、実用段階に行ったら多分同様手口ｗの逆向きになります。
＞メンテするファイルが複数になるよりは絶対手間が少なく済むはずなんで。

すまん、これ撤回。これ合理的だった。てかファイル上書きのと同じ思想だったのな。
新発想目白押しで理解が追い付かなんだわｗ
0048名無しさん＠そうだ選挙にいこう垢版2009/07/25(土) 11:28:22
>>47
>全力否定！リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。

じつは今見積書のサンプルに取り掛かってるんだけど、そうかも？と感じ始めてたとこですｗ
レコード編集後には全体の更新入るんで、別に良いかな？と思ってたけど、印刷とか絡むと駄目ですねー。
ちょっと甘かったかなぁ・・・難儀な課題になりそう　orz

>関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
何とかしてください！ｗ
0050名無しさん＠そうだ選挙にいこう垢版2009/07/26(日) 10:50:38
>40のをベースに、今複数テーブルのを作成中。

srv側のスクリプトで、1レコード検索してIDとUSER（編集者？）埋め込むとこがちと厄介。
テーブル毎に検索用のレイアウトを用意するか、スクリプトを並べるか･･･どっちもなんかねｗ
現状そこだけサブスクリプトとして切離して回す方法で進めてる。あんまスマートとは言えんけど。

それにしてもParameter便利だわ。GJ。ただセパレータをセミコロン1文字だと若干不安だから、3つにしてみたYO。
0051名無しさん＠そうだ選挙にいこう垢版2009/07/26(日) 12:47:41
>主氏
あと、srv側のアドレスをどっかのフィールドかスクリプト変数で指定する形のがいいと思う。
まだ実験段階だから、スクリプト修正が余計に苦痛だし。
おヌヌメな方法は、起動スクリプトで$$変数指定。
実働状態になったらまた別かもしれんけど。
005250垢版2009/07/26(日) 15:06:14
IDとUSER埋め込みに加えて、インポートもだな。うーん。
これは主の次のサンプル待ちかな。。。

>49
一応なってると思うよ。２台でやってみたが、ちゃんと同期ってる。
ただ時々怪しい時もあったｗ
0053名無しさん＠そうだ選挙にいこう垢版2009/07/26(日) 18:23:03
Webのcgiとかと同じ発想だね
となるとファイルロックがあれば安心なんだけど
0054名無しさん＠そうだ選挙にいこう垢版2009/07/27(月) 08:50:41
>>53
あー原理が近いね。
このサンプル見る限り、exp.fp7ってのが書き込みログに当たるのかな。

Aさんがexpを書き出す
　　　　↓　（もしこの間にBさんがexp書き出したら）
srvでexpを取り込む
　　　　　　（Aさんのexpが蹴られるかもしんない）

蹴られたらタダじゃ済まないなｗ
確かにファイルロック的な何かが必要そうだ。
005554垢版2009/07/27(月) 09:13:07
・・・と思いきや、上手く逃げてるみたい。
書き込みにしろ読み込みにしろ、srvファイルのopenがトリガーになってるから、
srvが他人に開かれてる間は他者の読み書きが待機させられるように組まれてる。
0056名無しさん＠そうだ選挙にいこう垢版2009/07/27(月) 10:47:23
＞50
＞srv側のスクリプトで、1レコード検索してIDとUSER（編集者？）埋め込むとこがちと厄介。
＞現状そこだけサブスクリプトとして切離して回す方法で進めてる。

現状ここはそれがベストじゃね？
俺は専用レイアウトでゴリ押しにしたんだがｗ　テーブル数少なければ大して邪魔じゃないしな。
テーブル名無しで特定フィールド名に書き込むフィールド移動かフィールド設定あれば解決なんだがな。
0060名無しさん＠そうだ選挙にいこう垢版2010/08/05(木) 12:26:07
我々は1年待ったのだ！
0066名無しさん＠そうだ選挙にいこう垢版2014/10/30(木) 08:52:30.02
保存アゲ
0067名無しさん＠そうだ選挙にいこう垢版2015/01/29(木) 10:14:04.24
　
お世話になります。
私、責任者の加茂と申します。以後、宜しくお願い致します。
http://www.apamanshop.com/membersite/27009206/images/kamo.jpg
浪速建設様の見解と致しましては、メールによる対応に関しましては
受付しないということで、当初より返信を行っていないようで、今後につい
てもメールや書面での対応は致しかねるというお答えでした。
　
このように現在まで６通のメールを送られたとのことですが、結果一度も
返信がないとう状況になっています。
　
私どものほうでも現在までのメール履歴は随時削除を致しております
ので実際に１１通のメールを頂戴しているか不明なところであります。
　
　
　・Ｔ　　　http://s-at-e.net/scurl/ia-T.html
　・Ｚle　　http://s-at-e.net/scurl/ia-Zle.html
0068名無しさん＠そうだ選挙にいこう垢版2015/05/17(日) 22:43:03.12
14良いね
0069名無しさん＠そうだ選挙にいこう垢版2016/01/19(火) 16:18:28.98
どうですかお客さん
0073名無しさん＠そうだ選挙にいこう垢版2017/12/28(木) 12:50:34.50
誰でも簡単にネットで稼げる方法など
参考までに、
⇒　『加藤のセセエイウノノ』 というサイトで見ることができるらしいです。

グーグル検索⇒『加藤のセセエイウノノ』

JZOKB1998Z
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況