09/07/23 13:27:43
補足。
思案の挙句、起動時のみサーバーファイルを上書き読み込み、
操作中の更新はインポートという形に落ち着きそうです。
削除対応は今回はスルーかもです。
ただ、操作中に削除済みレコード操作しようとする時は回避できてます。
あと起動時の上書き操作は任意のタイミングでできるのでほぼ問題ないはずです。
では。
40:名無しさん＠そうだ選挙にいこう
09/07/24 00:45:25
とりあえずサンプルとして、郵便番号の１テーブルで作ってみました。
URLﾘﾝｸ(karintou.mine.nu)
DLパス：fmrt
今回はランタイムではなく、ファイルメーカーのファイルです。
バージョンは９以降でお願いします。（８で正しく動作するかわかりません）
サーバー用のファイルはネットワーク先にも置けます。
複数人で運用可能です。
適当に弄ってみてください。
詳しい解説は明日以降に書く・・・つもりです。
41:名無しさん＠そうだ選挙にいこう
09/07/24 16:43:58
＞４０ おつ。まずあぷろだ判りにくすぎｗ変えたほうがいい。
URLﾘﾝｸ(www1.axfc.net) こっちお勧め。
で、ざっくり感想言うと、速度はネットの共有フォルダ程度なら何とかなりそうだ、と感じた。
１２万レコードでこの程度の速度出るなら実用範囲だと思う。
しかもやってみたらランタイムでも実際動くんだな。カスタマイズやメンテでFM必要にはなるが。
ただ、途中までローカルファイル上書きの設計で進めて頓挫したこっちの身にもなってくれｗ
このインポート式は完全に正攻法＆じゃないか。これで済むなら最初から上書き計画しなかったのに。
とにかくあれこれ弄ってみるよ。
で、現時点での問題点を晒してみる。
・ローカルファイルで開発→サーバーファイルを作る これは荒業すぎかも。
・更新レコードのインポート方法ちょっとエラー対策不足。ネット運用前提ならもう少し万全にした方がいい。
・ローカルで大量レコード表示状態でソートかかってるともたつくが、これはウィンドウ処理のせい。工夫で回避できそう。
・テーブル増えるとその分スクリプトも増える悪寒。
まぁまだ問題も未知数だしグレードアップの余地もありそうだし、現時点ではこれ以上評価難しい。
あと本題とはズレるが、何しろカスタム関数のParameterに感動した。
最初は意味よくわからんかったが、よくよく見るとすごいよこれ。
このカスタム関数のおかげでスクリプトがこんだけスマートになってるのな。
これはありがたく頂戴させてもらう。
42:名無しさん＠そうだ選挙にいこう
09/07/24 21:25:02
>>41
早速の試用レポ感謝です。
本当は解説をしておこうと思ってたんだけど、昨日は力尽きてｗ。解説より先にレスします。
>まずあぷろだ判りにくすぎｗ
すいません＾＾；今回は適当にググって済ませました。次回はお勧めのとこでうｐします。
>速度はネットの共有フォルダ程度なら何とかなりそうだ
そうですね。正直インポート型にすると先ず実用にならないって思ってたんだけど、
予想外に動きが良かったんです。固有ID（今回の〒）で運用前提ではありますが。
>しかもやってみたらランタイムでも実際動くんだな。
これは大前提ですからｗ 次回はランタイム版でアップ予定です。サイズ怖いけどｗ
>途中までローカルファイル上書きの設計で進めて頓挫したこっちの身にもなってくれ
まことに申し訳ないとしか言い様が無いです＾＾；
やっぱ検索状態の維持が不可能ってのは完全にお手上げだったんで。
複数テーブルの更新だとさすがに時間かかるんだけど、アクティブテーブルのみに
更新を絞っても運用上大した問題無さそうかなってことで、そうしたらインポート時間は
かなり速いし、全体的にすっきりしたんで、多分もう完全にこっち（インポート型）にします。
>ローカルファイルで開発→サーバーファイルを作る これは荒業すぎかも
そうなんだけど、実用段階に行ったら多分同様手口ｗの逆向きになります。
メンテするファイルが複数になるよりは絶対手間が少なく済むはずなんで。
～つづく～
43:名無しさん＠そうだ選挙にいこう
09/07/24 21:25:23
>更新レコードのインポート方法ちょっとエラー対策不足。
うーんファイル上書き型の時はもっと手抜きだったんですが＾＾；
もう少し開発進んだら検討してみます。
>ローカルで大量レコード表示状態でソートかかってるともたつくが、
>これはウィンドウ処理のせい。工夫で回避できそう。
その通りです。既に承知はしてます。ご理解が早くて怖いｗ
>テーブル増えるとその分スクリプトも増える悪寒。
もちろん。まぁ覚悟の上でｗ
>カスタム関数のParameterに感動した
これはバージョン８以降、どのシステムにも必ず組み込んでます。手前味噌だけど本当に便利。
ただ、変数名とかちゃんと把握して組まないと、エラー出ないんでデバッグが結構大変ｗ。
他にも日付を数値入力するやつとかも結構便利なんで、そのうち公開してみます。
今後ともよろしくです。
44:1
09/07/24 21:29:00
解説しようと思ったけど、長くなりそうなんで割愛します＾＾；
今回はとりあえず弄ってもらって、質問や意見等のレスだけにしたいと思います。
どうかご容赦を。
45:名無しさん＠そうだ選挙にいこう
09/07/25 00:08:26
サンプル拝見しました。
構造とかは今一理解に及んでないですが、とにかく共有はできるんですね。
無理が無いのなら、会社のシステムで、この仕組みを応用してみようと思います。
そこでいくつか質問させて頂きます。
１．複数クライアントで使う場合、どのようにすればできるんでしょうか？
複数台分のsrvファイルの同期方法がわかりません。
２．リスト表示や一覧表モードで、レコード編集する事はできないでしょうか？
３．〒userファイルで設定を修正したら、srvファイルも同様に修正しなければならないんでしょうか？
４．Parameter関数というのは何なのでしょうか？
５．レコード編集後に、「保存？復帰？」という選択がされるのは何故でしょうか？
初歩的な質問かもしれませんが、よろしくお願いします。
46:名無しさん＠そうだ選挙にいこう
09/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」を返します。
ようはスクリプト引数を多層化する目的のものですが、使い方次第で色んな事ができます。
>５．レコード編集後に、「保存？復帰？」という選択がされるのは何故でしょうか？
これはあまり意味は無いんですが＾＾；、「レコードの復帰」を擬似的に行うものです。
まぁファイル同期を利用して「こんなこともできます」って感じで表現しただけですｗ
また何かあったらお伝えください＾＾
47:名無しさん＠そうだ選挙にいこう
09/07/25 11:11:25
>>42
＞アクティブテーブルのみに更新を絞っても運用上大した問題無さそうかなってことで
全力否定！リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。
サンプルのは計算関係全くスルーだから問題なけど、通常使用ではそんなケースの方が少ない。
関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
・・・多少で済むかどうかはまだわからんが。
ところで
>ローカルファイルで開発→サーバーファイルを作る これは荒業すぎかも
＞そうなんだけど、実用段階に行ったら多分同様手口ｗの逆向きになります。
＞メンテするファイルが複数になるよりは絶対手間が少なく済むはずなんで。
すまん、これ撤回。これ合理的だった。てかファイル上書きのと同じ思想だったのな。
新発想目白押しで理解が追い付かなんだわｗ
48:名無しさん＠そうだ選挙にいこう
09/07/25 11:28:22
>>47
>全力否定！リレーション先のデータ次第で求める答えが違う場合はリレーション先の更新も絶対条件だよ。
じつは今見積書のサンプルに取り掛かってるんだけど、そうかも？と感じ始めてたとこですｗ
レコード編集後には全体の更新入るんで、別に良いかな？と思ってたけど、印刷とか絡むと駄目ですねー。
ちょっと甘かったかなぁ・・・難儀な課題になりそう orz
>関連レコードの表示を別ウィンドウで出して全部更新させれば、多少時間かかっても何とかなるから。
何とかしてください！ｗ
49:名無しさん＠そうだ選挙にいこう
09/07/25 12:36:25
これ本当に共有になってる？
同時進行でデータ更新されてないように見えるんだけど…どっか間違ってるのかな？
50:名無しさん＠そうだ選挙にいこう
09/07/26 10:50:38
>40のをベースに、今複数テーブルのを作成中。
srv側のスクリプトで、1レコード検索してIDとUSER（編集者？）埋め込むとこがちと厄介。
テーブル毎に検索用のレイアウトを用意するか、スクリプトを並べるか･･･どっちもなんかねｗ
現状そこだけサブスクリプトとして切離して回す方法で進めてる。あんまスマートとは言えんけど。
それにしてもParameter便利だわ。GJ。ただセパレータをセミコロン1文字だと若干不安だから、3つにしてみたYO。
51:名無しさん＠そうだ選挙にいこう
09/07/26 12:47:41
>主氏
あと、srv側のアドレスをどっかのフィールドかスクリプト変数で指定する形のがいいと思う。
まだ実験段階だから、スクリプト修正が余計に苦痛だし。
おヌヌメな方法は、起動スクリプトで$$変数指定。
実働状態になったらまた別かもしれんけど。
52:50
09/07/26 15:06:14
IDとUSER埋め込みに加えて、インポートもだな。うーん。
これは主の次のサンプル待ちかな。。。
>49
一応なってると思うよ。２台でやってみたが、ちゃんと同期ってる。
ただ時々怪しい時もあったｗ
53:名無しさん＠そうだ選挙にいこう
09/07/26 18:23:03
Webのcgiとかと同じ発想だね
となるとファイルロックがあれば安心なんだけど
54:名無しさん＠そうだ選挙にいこう
09/07/27 08:50:41
>>53
あー原理が近いね。
このサンプル見る限り、exp.fp7ってのが書き込みログに当たるのかな。
Aさんがexpを書き出す
↓ （もしこの間にBさんがexp書き出したら）
srvでexpを取り込む
（Aさんのexpが蹴られるかもしんない）
蹴られたらタダじゃ済まないなｗ
確かにファイルロック的な何かが必要そうだ。
55:54
09/07/27 09:13:07
・・・と思いきや、上手く逃げてるみたい。
書き込みにしろ読み込みにしろ、srvファイルのopenがトリガーになってるから、
srvが他人に開かれてる間は他者の読み書きが待機させられるように組まれてる。
56:名無しさん＠そうだ選挙にいこう
09/07/27 10:47:23
＞50
＞srv側のスクリプトで、1レコード検索してIDとUSER（編集者？）埋め込むとこがちと厄介。
＞現状そこだけサブスクリプトとして切離して回す方法で進めてる。
現状ここはそれがベストじゃね？
俺は専用レイアウトでゴリ押しにしたんだがｗ テーブル数少なければ大して邪魔じゃないしな。
テーブル名無しで特定フィールド名に書き込むフィールド移動かフィールド設定あれば解決なんだがな。
57:名無しさん＠そうだ選挙にいこう
09/07/29 09:30:10
>1
放置かよー
まぁ既に個別構築モードとも思えるが。
次サンプルは見ておきたい。
58:名無しさん＠そうだ選挙にいこう
09/08/09 12:17:34
ageage
59:名無しさん＠そうだ選挙にいこう
09/08/24 15:21:37
あげ