みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)
You are not logged in.
Pages: 1
FM12の初心者です。
テーブルが「計画」と「登録」と「バックアップ」の3個あります。
登録の検査フィールド入力のタイミングでバックアップに登録の計画No・作業名・作業者コードを入力させる方法をご指導願います。
入力には条件があります。
1.登録で指定する値(例えばABC)と計画の作業フィールドの値が同じ
2.登録の判定フィールドが0(ゼロ)であること
3.テーブル間はリレーションを使わないこと
宜しくお願い致します。
リレーションを使わないとするとテーブル間には関係がないということになるので、
登録で指定する値(例えばABC)と計画の「どのレコードの」作業フィールドの値を比べるのかが指定できなくなります。
リレーションを使わないとするとテーブル間には関係がないということになるので、
登録で指定する値(例えばABC)と計画の「どのレコードの」作業フィールドの値を比べるのかが指定できなくなります。
実はテーブルを沢山増やす必要がでました。その分リレーションも増えることになります。
変数を設定とフィールド設定を使うことによりリレーションが不要であると、何かで見た記憶があったので相談致しました。
やはりリレーションは必要でしょうか。
バックアップテーブルってどういうものでしょうか?
登録の検査フィールド入力のタイミングでバックアップに
登録の計画No・作業名・作業者コードを入力させる方法
これは、バックアップの新規レコードに
ということ?
Offline
変数でリレーションキーに相当する値を保存し、テーブルを移動してデータを抽出、その結果をインポート、という手順で、プライマリーのルックアップのような動作は可能でしょう。
また、ExecuteSQLでも同様の作業は可能です。
ただ、非常に煩雑なのと、その動作を動かすトリガーを設定していく必要があるため、入念な設計が必要でしょう。
リレーションで作業されたほうがトラブルは減ると思いますし、後のメンテナンス性も格段に良いと思います。
Offline
チポ様
ご指摘通り、バックアップテーブルとはバックアップの新規レコード作成のためです。
Shin様
私もリレーションの方が見やすいのでメンテナンス性が良いと考えているのですが、現システムは蜘蛛の糸状態です。
それに新たに追加すると益々増えることになります。
テーブル「計画」「バックアップ」はODBCタイプで、このたび基幹系への入力検討依頼がありまた。
IT部門よりリレーションが多いと急に入力が遅くなるのではと心配されました。
どの様な状態になると遅くなるのでしょうか。
リレーションが増えたから遅くなる、という事はありません。
そのリレーション先のデータがどのように参照されているかで、たった1個のリレーションでも遅くなることはあります。
現在のリレーションを整理されたらいかがでしょうか。まず、マップ上でリレーションのラインが交差しない様に、TOを配置し直す、という作業が必要なのでは。
Offline
登録とバックアップは常に同じレコードが有る。
ということですか?
とすると
バックアップの存在意味がなくなりそうですが。。
ファイルのバックアップなら別のファイルにしないと。
Offline
登録とバックアップは常に同じレコードが有る。
ということですか?とすると
バックアップの存在意味がなくなりそうですが。。ファイルのバックアップなら別のファイルにしないと。
FM入力データをそのまま基幹系に入力するために作成したODBCタイプのDBです。
間際らしい名称で申し訳ありません。
それではリレーションを前提で改めてご指導願います。
テーブルは「計画」「登録A」「登録B」の3個あります。
各テーブルのレコードは
「計画」
計画番号 工程番 判定
12345 A 1
12345 B 0
12345 C 0
23456 A 0
23456 B 0
23456 C 0
「登録A」
計画番号 あ工程番号 あ工程名 あ判定 い工程番号 い工程 い判定 う工程番号 う工程 う判定
12345 A あ 1 い B 0 う C 0
23456 A あ 0 あ B 0 う C 0
「登録B」
計画番号 工程番号 判定
12345 A 1
12345 B 0
12345 C 0
23456 A 0
23456 B 0
23456 C 0
相談したいのは「登録A」の各工程名(あ、い、う)の検査結果フィールドに入力すると「登録A」の各計画番号・工程番号・判定゙などを「登録B」に自動入力させる方法です。
但し「計画」と「登録A」の計画番号,工程番号,判定を比較し同じであることを確認するのが条件になります。
例えば「登録A」の計画番号12345,工程番号A,判定1と同じ値が「計画」にあることが条件になります。
上手く説明できませんが宜しくお願い致します。
#10の質問だけで考えますね。
登録Aのフィールドは計画番号だけにして、
他は登録Bのポータルにしたらいかがでしょう。
ポータル行に入力することで、登録Bにレコードが作られます。
また、その値の制限は、
計画テーブルとのリレーションで動的値一覧を作り、その値のみの制限が掛けられます。
Offline
申し訳ありませんが既に入力しているので、ポータルにすることは出来ません。
問い合わせを少し絞って相談いたします。
例えば「登録A」の「あ判定」フィールドの入力条件として
「計画」と「登録A」の下記フィールド値が同じであることです。
リレーション・スクリプト・スクリプトトリガなど、ご指導を宜しくお願い致します。
「計画」 「登録A」
計画番号 = 計画番号
工程番号 = あ工程番号
判定 = あ判定
登録Aの入力が登録Bのレコードになっていれば、
リレーションの設定とレイアウトの変更だけです。
現状のまま進めると、
リレーションのたびに
あ・い・う
それぞれ三つずつ設定するはめになりますよ。
Offline
Pages: 1
[ Generated in 0.007 seconds, 7 queries executed - Memory usage: 588.24 KiB (Peak: 604.78 KiB) ]