みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
いつもお世話になっています。
FM13 Win7使用です。
今度サーバーを購入することがほぼ決定したのでサーバーで使用することを前提として業務日誌を作成しています。
業務日誌は個人のものではなく所属している部署のもので、個別に記事を書き、それを1枚の紙にして出力or閲覧する予定です。
アカウントを20人分作成して運用したいと考えております。
入力方法は1レコードを1業務とし、入力終了した段階で記事を編集できないようにしたいと考えています(登録ボタンを作成し、スクリプトで制御したいですがここもよくわからない)。
また、記事を登録した際に登録者のアカウントと時間をどこかのフィールドに格納したいと思います。
一度登録した記事を編集する際にはロックの解除(スクリプトを作成する予定)を行ってからでないと編集できないようにしたいです。
この時も編集者のアカウントと時間を記録したいです。
お聞きしたいこととしては
①レコードのロックと解除の方法はどのようにするのがいいのか?
②一度登録した記事を編集する場合に、「いつ」「誰が」「どこを」「どのように」変えたのかわかるようにしたいです。
どのようにやるのがいいのでしょうか?
宜しくお願いします。
ロックを同様にかけるかにもよりますが、ロック解除の時に、元のレコードを複製してロック解除しておく、という方法が最も簡単かもしれませんね。
Offline
またまた横から失礼します。
①レコードのロックと解除の方法はどのようにするのがいいのか?
これもさまざまな手法がありますが、正攻法としてはアクセス権セット内の式を設定することで実現します。
簡易的にはフィールドにOnObjectModifyのスクリプトトリガを設定し、
If [TO名::ロック]
レコード/検索条件復帰[ダイアログなし]
End If
（ロックは数字フィールドでロック時1を入力）
といったスクリプトを割り当てるなんていう方法もあります。この手法はロック時に変更しようとするとカーソルが単に抜けるという動作になりますので、これをベースにいろいろ制御できます。
②一度登録した記事を編集する場合に、「いつ」「誰が」「どこを」「どのように」変えたのかわかるようにしたいです。
「いつ」「誰が」は、レコードが保存されたときにスクリプトトリガを起動し、ログ用テーブルにレコードを追加することでごく容易に実現できます。
「どこを」「どのように」のほうはちょっと面倒でして、要は履歴をすべて保存して比較をするような仕組みが必要になります。
ログインや変更の履歴を1回の変更ごとにレコード追加してゆくとレコード数が膨大になりますが、レコードとして増やしてゆくぶんには動作は重くなりません。ただし大きなファイルは別ファイルとしてバックアップ優先度を下げるほうがお勧めです。
という感じなのですが、雰囲気は伝わりますでしょうか。
- [FMhelp.jp] 有限会社アモニータ・茂田カツノリ http://www.fmhelp.jp/
Offline
Shin様
ありがとうございます。
ロックを同様にかけるかにもよりますが、ロック解除の時に、元のレコードを複製してロック解除しておく、という方法が最も簡単かもしれませんね。
ロックをかけることに関しては登録用Fを作成し、終了時に登録ボタンを押して登録Fに"登録"を入力するようにしたいと考えています。
登録が入力されていればフィールド内容の変更ができないようにしたいです。
再編集時は カスタムダイアログを表示→OKなら登録Fの内容を削除→編集後に再度ロックをかける という流れを考えております。
この登録Fの内容を削除する直前にレコードを他テーブルにインポート（もしくはフィールド内容のコピー）を行い、再ロック時にもう一回他テーブルにインポート（もしくはフィールド内容のコピー）を行うということでしょうか？
茂田カツノリ様
ありがとうございます
またまた横から失礼します。
①レコードのロックと解除の方法はどのようにするのがいいのか?
これもさまざまな手法がありますが、正攻法としてはアクセス権セット内の式を設定することで実現します。
簡易的にはフィールドにOnObjectModifyのスクリプトトリガを設定し、
If [TO名::ロック]
レコード/検索条件復帰[ダイアログなし]
End If
（ロックは数字フィールドでロック時1を入力）
といったスクリプトを割り当てるなんていう方法もあります。この手法はロック時に変更しようとするとカーソルが単に抜けるという動作になりますので、これをベースにいろいろ制御できます。
そのような方法もあるのですね。
修正不可にしたいフィールドが多数ある場合でも簡易的な方法でいけますでしょうか？
②一度登録した記事を編集する場合に、「いつ」「誰が」「どこを」「どのように」変えたのかわかるようにしたいです。
「いつ」「誰が」は、レコードが保存されたときにスクリプトトリガを起動し、ログ用テーブルにレコードを追加することでごく容易に実現できます。
「どこを」「どのように」のほうはちょっと面倒でして、要は履歴をすべて保存して比較をするような仕組みが必要になります。ログインや変更の履歴を1回の変更ごとにレコード追加してゆくとレコード数が膨大になりますが、レコードとして増やしてゆくぶんには動作は重くなりません。ただし大きなファイルは別ファイルとしてバックアップ優先度を下げるほうがお勧めです。
という感じなのですが、雰囲気は伝わりますでしょうか。
同じファイル内に作成せずに別ファイルにコピー（Buckup）をとっていくようなイメージでいいのでしょうか？
できるだけ動作は重くしたくないのですが・・・
単に、そのレコードを複製して、複製されたレコードの編集Fを解除、という手段です。複製された古いレコードは、何らかの方法でアクセス制限をかけておけば、単なる編集履歴として残りますね。
Offline
Shin様
ありがとうございます。
レコード複製も手の一つですね。ありがとうございます。
つたないながらやってみたのですが
履歴用Tを作成(フィールドは入力用Tと同じ)
レコード内容確定時に登録ボタンを押して登録Fに"登録済"を入力してレコードをロック(これはまだできていません)
修正の際には修正ボタンを押し、修正するレコードのみを履歴用Tへインポートしフィールド設定で登録Fを空欄に
修正が終了したら再度登録ボタンを押し、レコードをロックするとともに再度履歴用Tへインポートを行う
としてみました。
修正が1レコードに対して何十回も行われないと思いますので、ひとまずこれでやってみようと思うのですがどうでしょうか？
また、今回は同じファイル内にテーブルを作成しましたが茂田カツノリ様のいう通りに別ファイルに分けた方がいいのでしょうか？
宜しくお願いします。
連投すみません。
レコードロックの方法にういてもご教授お願いします。
出来れば登録Fが"登録済"の時にどのフィールドも変えられないようにしたいです。
宜しくお願いします。
履歴用テーブルなどは作らない方が良いと思いますよ。
運用のテーブルの中へそのまま保存しておき、アクセス権でアクセスを制限しておけば良いです。
こんな感じかな。
https://dl.dropboxusercontent.com/u/926 … 40.fp7.zip
Offline
閲覧や更新の履歴を保存し戻れるようにという考えは「監査証跡」とか「Audit Log」とかいうキーワードで語られる、システム系においては重要な概念です。
FileMakerにはその機能はありませんが、以下の製品を使えば簡単に付与することはできます。ちょっと高いのでおいそれとは導入できないのですが...。
http://syncdek.com/fmdataguard/
> 修正不可にしたいフィールドが多数ある場合でも簡易的な方法でいけますでしょうか？
先程の方法はそこがネックでして、全フィールドにスクリプトトリガを入れなきゃならないんですね。そのかわり変更しようとしたときの警告を制御したりと、ユーザビリティ向上の工夫がしやすいので、まあ場面次第です。
> 同じファイル内に作成せずに別ファイルにコピー（Buckup）をとっていくようなイメージでいいのでしょうか？
はい、そうですね。プロの現場では履歴だけの記録を別ファイルに取っておくことはよく行います。FileMakerはこうした履歴用テーブルにレコードが増えても動作への影響が少ないのですが、とはいえ長年使っていると肥大化するので、別ファイルによけておくのがいろいろ幸せです。
データを扱っているテーブル内で履歴のためにレコードを複製する手法は、データモデリングの原則から外れることと、仮に数値データを集計しているような場合に二重カウントになる点などに留意してご利用なさればと思います。
- [FMhelp.jp] 有限会社アモニータ・茂田カツノリ http://www.fmhelp.jp/
Offline
Shin様
ありがとうございます。
サンプルファイル確認させて頂きました。参考にさせて頂きます。
確認させて頂きたいのですが、
履歴用テーブルなどは作らない方が良いと思いますよ。
というのはどのような理由なんでしょうか？
申し訳ありませんがご教授お願い致します。
茂田カツノリ様
ありがとうございます。
閲覧や更新の履歴を保存し戻れるようにという考えは「監査証跡」とか「Audit Log」とかいうキーワードで語られる、システム系においては重要な概念です。
私もそう感じております。電子保存の3原則をこなすのがいかに大変か痛感しております。
> 修正不可にしたいフィールドが多数ある場合でも簡易的な方法でいけますでしょうか？
先程の方法はそこがネックでして、全フィールドにスクリプトトリガを入れなきゃならないんですね。そのかわり変更しようとしたときの警告を制御したりと、ユーザビリティ向上の工夫がしやすいので、まあ場面次第です。
今回ロックをかけたいのは全部で10フィールドほどです。個人的には問題ないと思っていますがどうでしょう?
> 同じファイル内に作成せずに別ファイルにコピー（Buckup）をとっていくようなイメージでいいのでしょうか？
はい、そうですね。プロの現場では履歴だけの記録を別ファイルに取っておくことはよく行います。FileMakerはこうした履歴用テーブルにレコードが増えても動作への影響が少ないのですが、とはいえ長年使っていると肥大化するので、別ファイルによけておくのがいろいろ幸せです。
データを扱っているテーブル内で履歴のためにレコードを複製する手法は、データモデリングの原則から外れることと、仮に数値データを集計しているような場合に二重カウントになる点などに留意してご利用なさればと思います。
そうなのですね。とりあえず同ファイルでやってみてものすごく増えるようだったら別ファイルにするとかはありなのでしょうか？
Pages: 1
[ Generated in 0.005 seconds, 7 queries executed - Memory usage: 554 KiB (Peak: 574.91 KiB) ]