板検索:
FileMakerAdvanceランタイムでデータ共有 (65)
まとめビュー
掲示板データを取得できませんでした。このスレッドは2chから削除されている様子です。
現在取得済みのレスのみ表示します。

1
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 11:04:32
Advanceでランタイムを作って、それを各クライアントにインストール、
サーバーに見立てたPCにデータファイルを置いて、各ランタイムでデータ共有。
そんな「ケチケチファイル共有大作戦」を構想実験中。


2
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 11:33:43
【目的とメリット】

・サーバー+クラ台数分というFMアプリ導入費を何とかしたい

例えば10台で運用するには、現状だと
pro(\34,200) * 10 + svr(\115,200) = \457,200
という費用が発生してしまう。
ランタイム運用なら開発側のAdv償却費程度(100%でも\52,200)

・OSとFMのバージョンアップによって発生するコストとライセンス追加問題を何とかしたい

バージョンアップも全クラ同時にアップグレードが必要になり、運用コストがバカにならない。
旧バージョンで組んだシステムにクラ追加したくても、ライセンスが入手できない。
ランタイム運用ならライセンスは無視できる(若干御幣覚悟w)

【懸念される問題】

・ランタイムは共有操作は一切出来ないので、特殊なデータ管理方法になる為、
 リスクが高く、保証もされていない
・同上理由で、データの受け渡しに複雑なプロセスとアクセスバッティング回避策が必要
・速度面で不利になるケースもあり、規模、データ量の制約がある・・・はず

3
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 12:53:15
たとえば10台でとか書いてるけど、10台あっても誰か1人しか使うことが出来ないじゃん。
今誰が使ってるか確認しながらなんて実運用に耐えられるんだろうか?
まだインスタントwebとか使った方がストレスなさそう。
コメント1件

4
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 12:59:11
>3
もうちょっとお待ちを。そのカラクリを書きますんで。

5
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 13:40:49
〜現状の基本概念〜

ランタイムはファイル共有操作は一切できないが、単独でファイルを開く事は可能であり、
それがOSのネットワーク共有フォルダにあってもローカル動揺に可能なので、その仕組みを利用する。
他のユーザーと同時にファイルを開けない。誰かが開いてる時は、他の誰かが開こうとしたら
エラー発生 →エラーの場合はN秒後に再実行 を繰り返す事で、共有は成り立つ。
・・・はずだが、ここにシステム依存なリスクが潜んでいる可能性が高く、最悪ファイルの破壊を想定しなければならない。

〜具体的な流れ〜

【1】ファイル閲覧・・・まず仮に、サーバーに見立てたPC「S」、クライアント「A」と「B」とする
。舛錬咾離侫.ぅ襦憤焚file-S)を開く
■船蹇璽ルディスクに「名前を付けて保存(以下file-A)」にて上書きする
file-Sを閉じる
以上のスクリプトを「ロード」とする
★つまり、データ閲覧はサーバー側ではなく、あくまでローカルにコピーしたファイルを使う。

【2−1】既存データを編集開始・・・仮にテーブル3のレコード15(以下T3R15と表記)を編集したい場合
file-Sを開く
file-AのT3R15のRCにfile-SのT3R15をインポート(これが必要かどうか検討中)
file-SのT3R15の「ロック」フィールド(以下RC)が1の場合→編集不可でfile-S閉じて終了。0の場合↓
file-SのT3R15のRCに1を入れる
file-S閉じる
以上のスクリプトを「編集」とする
★つまりfile-SのT3R15は誰かが編集してますよ〜というフラッグ(フィールドRC)のみを立てる。

【2−2】編集終了
編集されたT3R15の1レコードのファイル(file-SR)を、Sローカルにエクスポート保存する。
file-Sを開く
file-SのT3R15にfile-SRを上書きインポート・RC消去
file-Aを上書き
file-Sを閉じる

6
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 13:41:17
【3】新規レコード作成・・・仮にT5テーブルにレコード追加したい場合
file-Sを開く
T5に新規レコード作成、同レコードRC=1
file-Aにfile-S上書き
T5の新規レコードに移動
夏力後【2−2】実行

【4】レコード削除・・・仮にT7R30を削除する場合
file-Sを開く
T7R30のRCが1ならfile-S閉じて終了、0の場合は削除(ダイアログ等自由)
file-A上書き


実際にはスクリプト引数とGet ( スクリプトの結果 )を使って、上記全てのスクリプトは1つにまとめられる。

7
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 13:59:14
つまり、file-Sを開いたら即file-Aの上書きコピーをし、file-Sを開いている時間を
最小限に留める事により、あたかもデータ共有しているかの様な操作体系が狙い。

〜以下、現状で問題視している事〜

A.各クラが特定レコードを編集するという事を明示的に行う必要があり、
 例えばフィールド全置換えのような自由な編集を可能にするには工夫が必要。

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

C.編集後のレコードをfile-Sに返す時、最もバッティング動作が危険と思われる。
 これについては、S側にデータインポート中だという事を示すフラッグファイルを一旦置き、
 インポート完了後にそのファイルを削除する事により、他者がアクセスする時はこの
 フラッグファイルの有無で動作・待機をコントロール可能。


とりあえず、現状報告はここまで。質問・否定等何でも書いてくだしぁ。

8
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 14:29:00
とりあえず乙。なるほどね。概略はわかった…ような気がする。
もっとシンプルにならんもんかね?AとBで差分抽出して交換するみたいな。

あと、
>編集されたT3R15の1レコードのファイル(file-SR)を、Sローカルにエクスポート保存する。
>file-Sを開く
>file-SのT3R15にfile-SRを上書きインポート・RC消去

これこうする必要ある?直接Aからピンポイントでインポートすればって思うが、何か問題ある?
コメント1件

9
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 14:31:17
いや待てw、そもそもサーバーのファイルってどこで開くの?鯖?蔵?
だめだ何かちょっと理解及んでないわw 出直してくる。

10
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 15:04:45
>8
>これこうする必要ある?直接Aからピンポイントでインポートすればって思うが、何か問題ある?

サーバ側のファイルをローカルで開いて操作するんだけど、直接クラからインポートとなると、クラが複数で
インポート元が1つじゃなくなるんで、サーバーファイルにクラ数分のスクリプト用意する必要があります。
更新レコードファイルを、各クラで統一した保存先とファイル名にすることで、サーバー側のスクリプトを
一元化できるわけです。

ただそれが原因で>7のCっていう問題が発生するんですがね^^;

11
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 15:58:29
ちょっと参加してみます。宜しく。
正直本スレ見て無理じゃないかなと勘繰ってたんですが、
思ったよりイケソウナキガスルーです。

サンプルファイル的なものは無いでしょうか?
無ければ別にいいです。自分で作ってみますんで。
コメント1件


12
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 16:08:56
つインスタント Web機能
入力は出来ないけれどな。
コメント1件

13
1[sage]   投稿日:2009/07/19 16:15:31
>12
検討はしてみたけど、UI的に無理かなぁと。制約多すぎて。

14
1[sage]   投稿日:2009/07/19 16:17:18
>11
現時点でサンプルないっす。実働ファイルの改変で起こしたんで。
時間あったら作るけど、まだ未完成だし、ちと時間無いです。すまそ。

15
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 16:19:25
>1
>>ランタイム運用ならライセンスは無視できる(若干御幣覚悟w)
せっかく良スレ期待なんだが、この一文は喧嘩腰杉じゃないか・・・まぁ覚悟はわかったガンガレ。

ところでこれバージョンどのあたり対象?なんとなく10限定みたいな感じするが。
コメント1件

16
1[sage]   投稿日:2009/07/19 16:30:01
>15
喧嘩腰ってわけじゃないですがね^^; FM社に喧嘩売ってる意味合いは否定しませんがw
バージョンについては、私の手元のは9です。確かに10なら色々楽になりそうなんだけど・・・
スクリプト変数多用するんで、今回は8以降って感じで。

17
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 16:39:08
>■船蹇璽ルディスクに「名前を付けて保存(以下file-A)」にて上書きする

これ簡単に書いてるが、ネットワークトラフィックとか問題無いの?
毎回ウン百MBとかいちいち流せんだろ。ギガLAN前提としてもキツイと思うが。
小規模なら大丈夫だろうけど、うちじゃこの時点でアウト。
レコード修正時刻とかで改変レコード絞って抽出した方が賢いかと思う。
コメント2件

18
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 17:14:30
本スレの938です。
ざらっと読みましたが、結構工夫されてますね。
私の場合はノートの持ち出しと、帰社時の同期だけだったんで
事情が若干違いますが、似たような苦労をしました。

記憶を頼りに思い付いた点挙げてみます。

1.権限管理
これは共有で運用する以上、貴方のプランに限らず必要な事で、
基本と言えば基本ですが、徹底するとファイル更新が楽にできます。
17さんの言われる「編集済みレコード抽出」を避けて、ファイルごと
コピーを繰り返す設計をした理由は、私が想像するにはおそらく
更新スクリプトの複雑化を避けるって事だと見てますが
(違ってたらごめんなさい)、レコード編集権限、削除権限を徹底すれば
案外すんなりできるはずです。ご検討してみてください。

2.ファイル更新時刻管理
Aさんがファイル変更できる時間帯、Bさんの時間帯、という具合に
何らかのルールを設けると、バッティングブレークはかなり避けられます。
フラッグファイルという方法も非常に面白いのですが、そのフラッグファイル
そのものを壊す事も考えられるので、完全とは言えないように感じます。

3.更新作業をサーバーにさせる
各クライアントはレコード変更する毎に毎回更新ファイルを吐き出し、
サーバーは定期的にそのファイルを拾い集めるという考え方です。
サーバーもファイルメーカー或いはランタイムが動作しているのが前提と
なりますが、サーバーのファイルをあえてクライアントに触らせない手法です。
ただクライアントが増えたり減ったりする度にスクリプト書き直す必要があったり、
正直デメリットも無視できませんが。

今回はこの辺で。
コメント2件

19
名無しさん@そうだ選挙にいこう[]   投稿日:2009/07/19 17:50:30
始めてカキコです。

うちの会社も実はバージョンアップ問題に直面しています。
数年前にバージョン5のサーバーと20クライアントを導入したんですが、
現状残っているライセンスが1つだけで、そろそろ何とかしないといけない状況です。
追加ライセンスは当然5(6)は入手できないし、アプリケーションのバージョンアップは
8で試してみたけど、そのままやるとマトモに動かない事が判明しました。
それにそもそもOSがVistaだとバージョン6はサポート外です。orz

考えられる方法は、相当な時間とお金をかけて全てバージョンアップを断行するか、
もっとお金をかけて?DBマネージメントを他所に依頼するか、という状況です。
実際やっていることは大したことではなく、社員各自の日報やタイムカードの連携といった程度なんですが、
それでも各チーム毎に入力するようになってるため、現状のシステムは非常に好評ではあります。

こちらの内容を見た瞬間、「これだ!」と感じた次第です。
他の方のご指摘通り危険もあるかもしれませんが、私程度でも実現できるのであれば、
会社的にも大幅なコスト削減となり、私としても評価が上がってry) なので挑戦してみたいです。
今後ともよろしくお願いします。
コメント1件

20
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 18:10:00
この方法ってFM社視点だと営業妨害になんねーの?
ここじゃなくて他で非公開でコソーリやる方がよくね?
コメント1件

21
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 18:14:47
>17
同意。ネットワーク管理者にはおっかない仕様だな。
まぁ20MBくらいが一応のラインってとこかな。
逆にその程度の操作ならFMサーバーとPro使うよりもサクサクが期待できるのか?
蔵がUMPCとかだと意外に戦えるかもしれん

22
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 18:21:20
今ちょっと試してみたが、案外大丈夫だな。50MBくらいでもGbイーサなら楽勝だった。
期待していいのか?
ちなみにUMPCだとローカルディスクがもっさりで駄目ぽだ。無線だと尚更厳しそうだ。

23
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 18:24:01
連投ですまんが、>1はどの程度の規模でやってるのか教えてくれ。
色々難点がありそうだけど試す価値はありそうだ。
コメント1件

24
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 18:29:25
>18
>> 各クライアントはレコード変更する毎に毎回更新ファイルを吐き出し、
>> サーバーは定期的にそのファイルを拾い集めるという考え方です。
これ逆に難しくない?
同時に同じ人が同じレコード編集しようとした時、回避できないんじゃないかな?

25
24[sage]   投稿日:2009/07/19 18:31:14
訂正。
×同時に同じ人が同じレコード〜
○同時に別の人が同じレコード〜 ヤッチマッタ

26
1[sage]   投稿日:2009/07/19 21:22:37
>17
最初は変更レコードの抽出でスクリプト作ったけど、テーブル数が多いとチェックだけで
結構な時間要するんで、結果的にファイルごと読み込む方が速かったんです。
ファイルサイズは30MB程度ですが、読み込み時間は現状で1.5秒前後。我慢できる時間です。
でももっと大きくなると確かに無理があるかもしれませんねー。
ただ、同程度のファイルをFMサーバー無しの共有で運用するよりは、遥かに体感速度が速いです。
FMサーバー有りの場合はわかりませんが。

>19
大変ですねー。バージョン5〜6あたりが今一番そういう問題を宿してるような気がします。
私も6から7に移る時相当苦労しました。てか結局ほとんど作り直したんですがw
そもそもファイルシステム違いすぎて無理がありましたよね。
6→7の時のような大幅なシステム変更は今後もう無いかもしれませんが、
とりあえず今回のチャレンジが多少なりともお力になれたら幸いです。

27
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 21:32:03
>18
ご助言ありがとうございます。

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

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

>3.更新作業をサーバーにさせる
これも実は検討はしたんですが、考え方がまったく逆向きになりますよねー^^;。
出来そうではあるけど、ちょっと勇気が出ないというか、道のりが長そうと言うか。
もう少し具体的な部分やコツなどを教えて頂けたら助かります。

28
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 21:37:45
>20
コソーリだと情報の共有が不自由かなと。てか、もう立てちゃったんで許してくださいw
営業妨害・・・かどうかはまだ結果が出ないことにはw

>23
一応テーブル数21、最大レコード数は多いテーブルで約6万レコード、
フィールド数は多いテーブルで17、但しデータフィールドのみ。
ファイルサイズは現状31MBって感じです。

29
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 21:47:12
やっと整理した。
追っかけるの大変だ。
>1はコテ酉付けてくれると幾分読みやすくなるんだがどう?
コメント1件

30
1[sage]   投稿日:2009/07/19 22:03:50
>29
コテ酉・・・読めないけど、これ(1)でいい?

31
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 22:30:49
なんとなくサンプル的に作ってみました。
サーバとの受け渡しスクリプトは確かに1つですね、逆にそうしないと、複雑になりそうでした。

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

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

ここなんですが、操作してるAから別ファイル(C)のスクリプトを起動して、Cスクリプト上でAを閉じるって操作、どうしても無理なんです。
何か方法ありますか?それとも考え方が間違ってるのかな?
コメント1件

32
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/19 22:40:34
あと、Aファイルを操作してて、レコード編集に入る時にSから上書きって操作、本当に必要ですか?
これ結構無駄な気がしてならないんですが(´・ω・`)
サンプルで操作する分には、この上書きが何度されても、サイズ的に気にならないけど、
サイズ大きいファイルだと、こう何度も何度も上書きって、何か問題ありそうな気がしますが…。
せめて編集終了後だけにするなら、回数半分に減ると思うんです。

33
名無しさん@そうだ選挙にいこう[]   投稿日:2009/07/20 00:59:58
>1 おつです。
これ昔ちょっとやってみようって思った事だけど、時間に追われて結局断念したやつです。
どこで断念したのか曖昧だけど、Aさんが編集中にBさんが編集したら正解はどっち?みたいな感じだったかな。
フラグフィールドってのが当時思いついてたらちゃんと形にできてたかも。
とりあえず参考にさせていただきます。

>31
アツカマシイけど、そのサンプル晒してもらえませんか?自分でもちょっとやってみたいんで是非。

34
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/20 10:52:37
ぬぅ・・・自力では無理かやっぱ・・・これ凄いエゲツナイほどステップ多くならん?
あとローカルでせっかく細かい検索条件やらして絞り込んでも、上書きで乙だわな。
スレ主よ、もうちっと細部晒すか、サンプル出してくれ。頼むわ。
なんか物凄く無駄足踏んでるような気がする。
コメント1件

35
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/20 12:33:32
>34
同じく行き詰まりまくり。なんか本当にできるのか怪しくなってきた orz

>1氏は今日はお休み?
>31さん読んでたら進捗とかどないで?

36
1[sage]   投稿日:2009/07/21 08:28:07
あーすいません、昨日は完全休日で何もしませんでしたw
てか。。。もう作り始めた人いたんだぁ^^;恐縮っす。

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

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

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

>あと、Aファイルを操作してて、レコード編集に入る時にSから上書きって操作、本当に必要ですか?
これ必要ないっす。上書きじゃなくて1レコードインポートです。自分の書き方足りなかったかも^^;。
ただ確かにファイル丸ごと上書き連射は、ちょっと考え直そうかなと思案中。
狙い撃ちインポートだと、見ているテーブルだけに絞ったりとか、何らかの合理化が必要ですねー。

37
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/21 08:39:25
>34-35

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

うっ・・・おっしゃるとーりでございます orz
ローカルでの最終検索条件を引き継いだり、色々思案したけど、どうもうまく行かない。
これも付いて回る大問題。インポートのが色んな意味で安定しそうっす。
インポートのが巧く動きそうなら、上書きは断念な方向になりはじめてますw

38
1[]   投稿日:2009/07/23 13:21:18
ただいまインポートエクスポートスタイルでサンプル作成中。
レコード削除の同期が大変ですねー。ファイル上書きなら全く問題にならなかったけど。
削除済みリストのグローバルフィールドを毎回覗く形で何とかなりそうだけど、
スクリプトが煩雑になりそうな悪寒。
まぁとりあえず今日中に最初のやつアップしてみます。

39
1[]   投稿日:2009/07/23 13:27:43
補足。
思案の挙句、起動時のみサーバーファイルを上書き読み込み、
操作中の更新はインポートという形に落ち着きそうです。
削除対応は今回はスルーかもです。
ただ、操作中に削除済みレコード操作しようとする時は回避できてます。
あと起動時の上書き操作は任意のタイミングでできるのでほぼ問題ないはずです。
では。

40
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/24 00:45:25
とりあえずサンプルとして、郵便番号の1テーブルで作ってみました。
http://karintou.mine.nu/uploader/download/1248363644/attach/FMRT_test...
DLパス:fmrt

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

適当に弄ってみてください。
詳しい解説は明日以降に書く・・・つもりです。

41
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/24 16:43:58
>40 おつ。まずあぷろだ判りにくすぎw変えたほうがいい。
http://www1.axfc.net/uploader/O/ こっちお勧め。

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

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

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

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

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

あと本題とはズレるが、何しろカスタム関数のParameterに感動した。
最初は意味よくわからんかったが、よくよく見るとすごいよこれ。
このカスタム関数のおかげでスクリプトがこんだけスマートになってるのな。
これはありがたく頂戴させてもらう。
コメント1件

42
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/24 21:25:02
>41
早速の試用レポ感謝です。
本当は解説をしておこうと思ってたんだけど、昨日は力尽きてw。解説より先にレスします。

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

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

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

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

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

〜つづく〜
コメント1件

43
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/24 21:25:23
>更新レコードのインポート方法ちょっとエラー対策不足。
うーんファイル上書き型の時はもっと手抜きだったんですが^^;
もう少し開発進んだら検討してみます。

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

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

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

今後ともよろしくです。

44
1[sage]   投稿日:2009/07/24 21:29:00
解説しようと思ったけど、長くなりそうなんで割愛します^^;
今回はとりあえず弄ってもらって、質問や意見等のレスだけにしたいと思います。
どうかご容赦を。

45
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/25 00:08:26
サンプル拝見しました。
構造とかは今一理解に及んでないですが、とにかく共有はできるんですね。
無理が無いのなら、会社のシステムで、この仕組みを応用してみようと思います。


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

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

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

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

4.Parameter関数というのは何なのでしょうか?

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


初歩的な質問かもしれませんが、よろしくお願いします。
コメント1件

46
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/25 10:48:17
>45
>1.複数クライアントで使う場合、どのようにすればできるんでしょうか?
  複数台分のsrvファイルの同期方法がわかりません。
〆能蕕縫ぅ鵐好函璽襪靴織ライアントでsrvを作り、どこかの共有フォルダに移動する
▲ライアントの「〒user1」ファイルのスクリプト「サーバー処理」の手直しをする(ReadMe参照)
次にインストールしたいクライアントに、最初のクライアントのフォルダをコピーをする
・・・つまり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

また何かあったらお伝えください^^

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

ところで

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

すまん、これ撤回。これ合理的だった。てかファイル上書きのと同じ思想だったのな。
新発想目白押しで理解が追い付かなんだわw
コメント1件

48
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/25 11:28:22
>47
>全力否定!リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。

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

>関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
何とかしてください!w

49
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/25 12:36:25
これ本当に共有になってる?
同時進行でデータ更新されてないように見えるんだけど…どっか間違ってるのかな?

50
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/26 10:50:38
>40のをベースに、今複数テーブルのを作成中。

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

それにしてもParameter便利だわ。GJ。ただセパレータをセミコロン1文字だと若干不安だから、3つにしてみたYO。

51
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/26 12:47:41
>主氏
あと、srv側のアドレスをどっかのフィールドかスクリプト変数で指定する形のがいいと思う。
まだ実験段階だから、スクリプト修正が余計に苦痛だし。
おヌヌメな方法は、起動スクリプトで$$変数指定。
実働状態になったらまた別かもしれんけど。

52
50[sage]   投稿日:2009/07/26 15:06:14
IDとUSER埋め込みに加えて、インポートもだな。うーん。
これは主の次のサンプル待ちかな。。。

>49
一応なってると思うよ。2台でやってみたが、ちゃんと同期ってる。
ただ時々怪しい時もあったw

53
名無しさん@そうだ選挙にいこう[]   投稿日:2009/07/26 18:23:03
Webのcgiとかと同じ発想だね
となるとファイルロックがあれば安心なんだけど
コメント1件

54
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/27 08:50:41
>53
あー原理が近いね。
このサンプル見る限り、exp.fp7ってのが書き込みログに当たるのかな。

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

蹴られたらタダじゃ済まないなw
確かにファイルロック的な何かが必要そうだ。

55
54[sage]   投稿日:2009/07/27 09:13:07
・・・と思いきや、上手く逃げてるみたい。
書き込みにしろ読み込みにしろ、srvファイルのopenがトリガーになってるから、
srvが他人に開かれてる間は他者の読み書きが待機させられるように組まれてる。

56
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/27 10:47:23
>50
>srv側のスクリプトで、1レコード検索してIDとUSER(編集者?)埋め込むとこがちと厄介。
>現状そこだけサブスクリプトとして切離して回す方法で進めてる。

現状ここはそれがベストじゃね?
俺は専用レイアウトでゴリ押しにしたんだがw テーブル数少なければ大して邪魔じゃないしな。
テーブル名無しで特定フィールド名に書き込むフィールド移動かフィールド設定あれば解決なんだがな。

57
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/07/29 09:30:10
>1
放置かよー
まぁ既に個別構築モードとも思えるが。
次サンプルは見ておきたい。

58
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/08/09 12:17:34
ageage

59
名無しさん@そうだ選挙にいこう[sage]   投稿日:2009/08/24 15:21:37
あげ

60
名無しさん@そうだ選挙にいこう[]   投稿日:2010/08/05 12:26:07
我々は1年待ったのだ!

61
CADソフト専門店[soft@jp-cad.com]   投稿日:2011/04/08 17:08:47
Filemaker 激安
詳しくは ホームページ: http://www.jp-cad.comをご覧ください。

62
名無しさん@そうだ選挙にいこう[sage]   投稿日:2012/08/20 19:45:38
age

63
名無しさん@そうだ選挙にいこう[sage]   投稿日:2012/10/08 08:23:08
創・価
死・ね
創・価
死・ね 
創・価
死・ね 
創・価
死・ね
創・価
死・ね
創・価
死・ね 
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね 
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね

64
名無しさん@そうだ選挙にいこう[sage]   投稿日:2013/10/22 19:49:40
FileMakerAdvanceランタイムでデータ共有

65
名無しさん@そうだ選挙にいこう[sage]   投稿日:2013/11/24 20:55:21
千葉県松戸市六高台2-78-3
更新情報
・スレッド一覧ページで過去ログのタイトル検索・一覧表示ができるようになりました(2016/1/20)
NGワード登録
登録する
スレッド内検索

ビジネスsoft板 タイトル検索

このスレッドが人気です(実況系)
実況 ◆ フジテレビ 82628 出家 (1000)フジ実況
実況 ◆ 日本テレビ 54261 カルト対893 (999)NTV実況
羽鳥慎一モーニングショー★2 (524)テレ朝実況
実況 ◆ テレビ朝日 46858 (902)テレ朝実況
実況 ◆ フジテレビ 82629 (152)フジ実況
連続テレビ小説 べっぴんさん★180 (939)NHK実況
白熱ライブ ビビット★1 (204)TBS実況
はやドキ!& あさチャン!月曜日★2 (379)TBS実況
このスレッドが人気です(ニュース系)
かばんから狆っ恥ずかしい瓠崑膺佑里もちゃ」 警察の所持品検査は「プライバシー侵害」と驚きの賠償命令…現場は震撼 (559)ニュー速+
【芸能】「出家します」清水富美加が電撃引退!『幸福の科学』活動専念へ★21 (1000)音楽・芸能ニュース
【政治】“田舎臭い少女風” 稲田防衛相のファッションに悪評[週刊新潮] (394)ニュー速+
【デッドライジング】 もしゾンビが大量発生したらどこに逃げるのが正解? (41)ニュー速
【芸能】「出家します」清水富美加が電撃引退!『幸福の科学』活動専念へ★22 (110)音楽・芸能ニュース
【社会】岐阜・金津園のソープランド摘発、岐阜県警 売春防止法違反の疑い (67)ニュー速+
【芸能】「出家します」清水富美加が電撃引退!『幸福の科学』活動専念へ★20 (1000)音楽・芸能ニュース
【静岡】イスラム教徒の保護者、「ハラール対応」ではない学校給食に苦慮 ムスリムへの理解と柔軟な対応求める★29 (1000)ニュー速+
ビジネスsoft板の人気スレ
Excel総合相談所 125 (585)
一太郎総合スレッド その18 (484)
Office2010/2013アクティベーション総合スレッド part5 (898)
Office2010/2013アクティベーション総合スレッド part3 (994)
【FileMaker】ファイルメーカーユーザの集い Part2 (996)
【質問不可】Excel総合相談所スレの雑談・議論スレ3 (909)
こいつを警察に通報してください (281)
Word(ワード)総合相談所 Part22 (926)
AutoCAD総合スレ part6 (176)
一太郎総合スレッド その16 (1011)
AutoCAD総合スレ part4 (990)
LibreOffice/OpenOffice.orgってどうなの?Part16 (988)
ファイルメーカーユーザの集い Part3 (822)
【MS互換】KINGSOFT Office Part6【VBA対応】 (758)
DWG【DraftSight】FreeCAD (970)
【MS】Office 365 総合スレ 【クラウド】 (996)
LibreOffice/Apache OpenOffice 総合相談所 11 (1007)
一太郎総合スレッド その15 (990)
LibreOffice/Apache OpenOffice 総合相談所 12 (624)
[test] 書き込みテスト 専用スレッド [てすと] (246)
Access総合相談所 27 (457)
エクセル対三四郎 (459)
Groupmax (134)
桐について語るスレ 3 【サーバー未満 Excel以上】 (638)
▲▼▲カルキングの広場▲▼▲Part 1 (178)
【監視される社員たち】LanScope【人権侵害?】 (330)
アドビ、不細工アクティベーションやめろや (117)
【独占】ゼンリン地図不買運動【傲慢】 (592)
このサイトについて
このサイトは2ちゃんねるからデータを取得し、表示するサービスです。
画像のインライン表示機能について
画像のURLの後ろにある[画像をインライン表示]をクリックすると、URLの下に表示します。
表示される画像は横幅100pxに縮小されていて、クリックすると原寸で表示します。
このサイトの特徴
1)スレッド内検索ができます
2)レス(「>>1」など)のポップアップができます
3)不適切な言葉を含む投稿を表示しません
4)ページ内で画像を直接表示できます
5)2ch他スレッドへのリンクはタイトル・板名つきでリンクします
6)すっきりとしたデザインで表示します
7)最新スレや前スレをチェック・一覧表示します
8)NGワード機能の搭載でイヤな言葉が目に入りません
9)荒らしを自動チェックします
10)スレッド内・同一IDの書き込みだけ表示できます
11)レスの返事をレスされた発言の下に表示する「まとめビュー」が利用できます
12)シリーズ化したスレッドの一覧を表示します
13)最新のスレッドがある場合はお知らせします
削除について
こちらをご覧ください
機能要望について
現在機能要望受付中です。
問い合わせについて
こちらのページからどうぞ
Amazon


このサイトは2ch.scからデータを取得・表示しています。削除などについてはこちらをご覧ください。 アクセスモード: