みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
レコードインポート時に、インポート元で複数のレコードが検索されている状態で、
現在レコードのみをインポート対象にしたいと思っております。
概要は次のとおりですので、ご教授くださいますようお願いいたします。
学生名簿DBから同窓生名簿DBへ、関連データをインポートします。
各DBのテーブルは次のとおりです。
（学生名簿DB）
学生氏名
保証人氏名
保証人郵便番号
key（保証人氏名＋保証人郵便番号）※インポート時の照合フィールド
（同窓生名簿DB）
同窓生氏名
同窓生郵便番号
子１
子２
子３
甥
姪
key（同窓生氏名＋同窓生郵便番号）※インポート時の照合フィールド
・同窓生の御子弟が学生として在籍しているため、同窓生DBの子１・子２や
甥・姪フィールドに、学生氏名をインポートしたいと思っています。
（手順）
・同窓生は学生の保証人（通常は父母）となっているため、同窓生DBのkeyで
学生DBのkeyフィールドを検索します。
・同窓生が複数の御子弟の保証人となっているケースがあるため、検索結果は、
必ずしも1対1とはならず、検索結果は複数件となる場合があります。
・例えば、3件の検索結果となった場合、同窓生の学生との続柄を順に確認し、
インポート先の同窓生DBのフィールドを変更したいと思っております。
（学生名簿DB） （同窓生名簿DB）
学生A 保証人-同窓生D（父） ---> 同窓生DBの子１フィールドにインポート
学生B 保証人-同窓生D（父） ---> 同窓生DBの子２フィールドにインポート
学生C（男） 保証人-同窓生D（叔父）---> 同窓生DBの甥フィールドにインポート
・各種処理はスクリプト内で、Loopやif等により、実現できているのですが、
検索結果が3件等の複数となった場合、最後のレコード（例では学生Cの氏名）が、
同窓生DBの子１、子２、甥フィールドにインポートされてしまいます。
解りづらい説明で申し訳ありませんが、インポートの際、インポート元で
複数検索されている状態で、インポート対象をカレントレコードとすることは
できないでしょうか。
よろしくお願いいたします。
「インポート時に、インポート元で複数のレコードが検索されている状態で、現在レコードのみをインポート対象に」するのは不可能です。
質問のケースでは、
List（学生名簿::学生氏名）
で転記すべき情報は各レコードで取得できるので、GetValue()で1つずつフィールドに入れればいいです。インポートは不要です。
List()だと空欄が詰められてしまいますが、学生名簿の書いてないフィールド（続柄・性別）は空欄禁止になってますか？
現状だと甥や姪が複数いた場合に対応できませんね...
「key（同窓生氏名＋同窓生郵便番号）」というのも、現実的にはあまり問題ないにしても、理論的には重複可能性があってよくないです。
内容は理解できていませんが、、
対象レコードを崩さないで、現在のレコードのみインポートしたい。
なら、
別ウインドウにして、1レコードのみを対象としてインポート
ウインドウを閉じる。
でいいのでは。
Offline
データベースの構造設計が良くないでしょう。
まず、在校生も、退学した場合は扱いが変わるかもしれませんが、卒業後は同窓会へ入ることになるでしょうから、その基本的な名簿は一体化するべきです。それ以外の保証人も、同じテーブルに登録します。その上でそのそれぞれにIDを与えておきます。在校生、同窓生以外も、基本的な情報を保存するテーブルとして使います。（一部の在校生の家族は同窓生でしょうから、同じテーブルで扱うべきでしょう）
key（保証人氏名＋保証人郵便番号）は、郵便番号は永続的に同一のものではなく、保証人氏名も永続的に同一とは限らないので、私なら永続的にはまず使わない構造です。
その一人ひとりの基本テーブルの ID を、別のテーブルで繋いで行きます。家族間系を保存するテーブルに、同窓生ID と、その家族の ID を1IDごとに1レコードとして、関係性（同窓生からみて子とか甥など）と共に保たせていきます。
別のテーブルで、在学生ID から、保証人のID（1IDごとに1レコード）を保存していきます。この関連性は、上の家族関係テーブルを参照すればひきだせます。（通常は、家族関係テーブルの中から、このテーブルへ設定することになるでしょうが）または、保証人を個人登録した時点で、在校生を検査できるような仕組みを作っておく（一時的なリレーションなので、保証人氏名＋保証人郵便番号 のようなリレーションキーでもいいです）を作っておけば、今やっているようなややこしい処理は全く不要になります。
という構造にすれば、複数の関係があっても、何も考えずに設定できます。
Last edited by Shin (2022-11-19 10:51:18)
Offline
自然な動きの運用ができるサンプルです。構造はかなり凝った動きになっていて、なかなか時間がかかりました。#5の提案を形にしたものです。
https://fm-aid.com/bbs2/viewtopic.php?pid=80932#p80932
ポータルのフィルターを使って、保証人氏名＋保証人郵便番号 での絞り込みもできます。
親戚関係の設定はなかなか面倒で、例えば、兄について、父母兄弟叔父叔母などの設定を行った場合、その弟からみると、非常によく似た設定になるはずですが、その関係を追って自動的に設定するのは、なかなか難しいです。
Last edited by Shin (2022-11-21 22:40:39)
Offline
皆様
返信が大変遅くなり申し訳ありません。
shin様のご指摘のとおり、データベースの設計が良くはないのだと認識しています。
組織体制に連動せざるを得ないところがあり、「学生名簿・成績管理」と「同窓会」が別々となります。
ちなみに、同窓会は大学の外郭団体的な扱いとなり、当該スタッフも大学職員ではありません。
現在、苦肉の策でkeyとして扱っている「保証人氏名＋保証人郵便番号」についても、ご指摘のとおり、
永続的に使用すべきものではなく、保証人が住所を移転して、その御子弟が入学されれば、
紐づけができません。
現時点で保証人や親権者の生年月日の登録がないため、少し苦労しております。
ご指摘の点とご提供いただきましたサンプルファイルを拝見し、検討してみます。
取り急ぎお礼申し上げます。
現在，同窓会側のファイルを見ているのですから、そこへのアクセスについては許可されているという事でしょう。でしたら、こちらのファイルに同窓会のIDを持つレコードを追加して、IDでリレーションしておきます。(多くの同窓会で，学生の番号をそのまま流通していることが多いです) 基本データはそちらを参照する仕組みにしておけば、1テーブルのような運用が可能ですよ。
完全にファイルを統合しても、同窓会と在校生関連でアクセス権を変えれば、同窓会職員には在校生部分へのアクセスを禁止する、という運用はできます。または、同窓会部分は、単なる名簿部分のみを使うことにして、今回は考慮しないでもいいのでは。（そこに追加されていくデータは、学校側にあるはずです）
学校側の職員は、同窓会会員はかつての生徒ですから、基本的情報をアクセスすることについて問題はないはずです。
純粋な学生名簿は、サンプルの中の個人テーブルから、学年、クラスのテーブルを作り関連づけると、そのテーブルの内容が在学生名簿になります。ですから、成績管理などの別テーブルの中で行われますので、同時に考えなくていいのでは。
成績管理をちょこっと追加してあります。クラス毎、全体の平均点、標準偏差が計算されます。これを基にして発展させれば実用にできると思いますが、実運用を全く知らないのでいじってみてください。
https://www.dropbox.com/s/ndtna9zzb07w8 … 2.zip?dl=0
Last edited by Shin (2022-11-25 17:45:12)
Offline
[ Generated in 0.007 seconds, 9 queries executed - Memory usage: 590.95 KiB (Peak: 607.86 KiB) ]