- ベストアンサー
3つのテーブルの画面表示について
- 3つのテーブルの画面表示方法について考えています。AとBの画面を作成し、Bの情報を入力後、Bの帳票を選ぶとBとCのメイン・サブフォームが表示され、Cの明細を入力できるようにします。もう一つの方法は1つの画面でBとCを両方サブフォームとして配置し、Bのレコードを選択するとCの明細が表示される方法です。
- 3つのテーブルの画面表示については、2つの方法を考えています。まず、AとBの画面を作成し、Bの情報を入力してから帳票を選択する方法です。もう一つは、BとCを両方のサブフォームとして1つの画面に配置し、Bのレコードを選択するとCの明細が表示される方法です。
- 3つのテーブルの画面表示には2つの方法が考えられます。まず、AとBの画面を作成し、Bの情報を入力してから帳票を選択する方法です。もう一つは、BとCを両方のサブフォームとして1つの画面に配置し、Bのレコードを選択するとCの明細が表示される方法です。
- superwonderful
- お礼率66% (90/136)
- その他MS Office製品
- 回答数9
- ありがとう数19
- みんなの回答 （9）
- 専門家の回答
質問者が選んだベストアンサー
私が思う１番簡単な方法です ・各テーブルを元に帳票フォームを作成しておきます A table → フォーム名 FA B table → フォーム名 FB C table → フォーム名 FC ・新規フォーム F1 をデザインで開きます（単票フォーム） ・そこにテキストボックス txt1、txt2 の２つを非表示で作成します ・出来上がっているフォーム FA ～ FC をドラッグ＆ドロップで組み込みます ・サブフォームコントロール FB をクリックして リンク親/子フィールドを設定します（手入力で） リンク親フィールド：txt1 リンク子フィールド：ID1 ・サブフォームコントロール FC をクリックして リンク親/子フィールドを設定します（手入力で） リンク親フィールド：txt2 リンク子フィールド：ID2 ・フォーム FA のレコード移動時に以下を記述します Private Sub Form_Current() Me.Parent.txt1 = Me.ID1 End Sub ・フォーム FB のレコード移動時に以下を記述します Private Sub Form_Current() Me.Parent.txt2 = Me.ID2 End Sub ・一連の変更を保存して、フォーム F1 を表示/操作してみます 余談） 上記は同じ階層にサブフォームを配置しましたが、 子サブ、孫サブ・・・ 使えるかどうかわからない方法については、ブログで記事にしていました。 が、ここにはアドレスを記述できないので、興味あれば探してみてください。
その他の回答 (8)
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
【お詫び】全ての回答をキャンセル！ 当初の質問では、全く、全容が見えなくて・・・。だが、徐々に。 仮に添付図のようなテーブル構造だとします。この場合の入力フォームは、実に、構想者によって千差万別。そこには最適解などありません。 よって、全ての回答をキャンセルします。 PS、再質問を！
お礼
ご回答ありがとうございます。 まあ、図のような感じですが、未だに、行番号をなんでいれんの・・・と思っています。 よろしくお願いします。
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
【確認】もしかして・・・ 依頼物件は、複数工事の複合受注なんじゃー。だとすれば、明細物件がある区分で分類される筈。例えば、主工事、副工事、附帯工事etc。ならば、当然に明細を規定の区分に応じて入力することになります。この場合、 ID 依頼物件台帳_ID 区分 行番号 ・・・ という風にすべきが筋。 先の安直なやり方は、定型的な区分入力ではない場合のこと。 ※念のために補足しておきます。
お礼
ご説明ありがとうございます。 この説明では ・ID→2個で主キーとなり、サブフォームと連結するということでしょうか？ ・区分→ ・依頼物件台帳ID よろしくお願いします。行番号はなんですか？
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
【提案】安直な解決が一番！ ともかく、全てをシンプルかつ安直というのが一番。そういう意味では、発想を転換されたらどうですか？ 先ず、新しい添付図を見て下さい。 変更点=列[受注No.]を新しく加えています。 =================================================== テーブル[依頼物件台帳]に枝番を有する列[受注No.]を設けるだけで、全く、何の変哲もない主表・従表関係が出来上がります。また、受註管理番号で管理するってのは普通どこでもやっていますので従来のに枝番を付加しただけです。 ・呼び出しは、列[受注No.]昇順にすれば全く問題ありません。 ・依頼物件工事高は、非連結で可。明細を合計すれば事足ります。 一番安直な解決手段ですが・・・。色々と仕掛けるよりもよいのでは・・・。 ※先の回答で実際に入力できるところまで完成させる作業の途中でこのような結論に！
お礼
ご回答ありがとうございました。 折角ご説明していただいたのですが、このテーブル構成は、当社の業務には当てはまらないと思いました。 よろしくお願いします。
- 30246kiku
- ベストアンサー率73% (370/504)
＃２です テーブルの設計は、 業務に精通した方が考えられたものを尊重された方が良いと思いますけど・・・ B table に 会社ID がある事について、 どう考えて居られるのかわかりませんが・・・ 安易に排除できるフィールドとも思えませんが・・・・ 例えば、依頼されたものを、孫請けに・・・ と解釈できなくもない・・・ 本質問の趣旨は、 ID1、ID2 をどう結び付けて、連動させて、表示/操作するか・・・ ということで回答してみましたが、 趣旨が異なるのであれば、スルーしてください。 というより、回答はなかった事にしてください。
お礼
#2 30246kikuさん >業務に精通した方が考えられたものを尊重された方が良いと思いますけど・・・ →業務の内容を調べながら、テーブル設計するのはとても大変ですが、やりがいが有ります。フォローありがとうございます >安易に排除できるフィールドとも思えませんが・・・・ 出来ません。排除すると役に立ちません。必要だからいれています。こういう構成をかんがえるのも大変でしたが。 >例えば、依頼されたものを、孫請けに・・・ と解釈できなくもない・・・ その通りです >本質問の趣旨は、 >ID1、ID2 をどう結び付けて、連動させて、表示/操作するか・・・ >ということで回答してみましたが、 ありがとうございます。適切な回答でした。 親→子→孫という表現の仕方で検索もしてみます。
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
【補足】明細工事名、明細工事別完成日等の処理。 附票的テーブルを明細にリンクさせるのが原則的なやり方。でも、面倒と言えば面倒。私なら、明細テーブルに持たせるかも知れません。 ＊ハードの性能向上と共にセオリーも変わる！
補足
ご回答ありがとうございます。 このご説明、もう少しわかりやすく説明していただけませんでしょうか。意味がわかりません。
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
だとしても、３つのテーブルという設計は100%ありません。 【依頼物件明細】 ID 依頼物件台帳_ID 工事カウンター 行番号 項目名 単位 数量 単価 つまり、 依頼物件台帳_ID 工事カウンター 行番号 の複合キーに対応する明細があるだけ。メインフォームでは、[工事カウンター]のMAX値を表示し、工事カウンター=1、工事カウンター=2に対応する明細を表示するのみ。 と、思いますよ。
補足
ご回答ありがとうございます。 つまり、二つの項目を主キーにして、親のテーブルとリレーション関係を作るということでしょうか。 【依頼テーブル】（受注） ・依頼ID ・依頼元会社 ・依頼内容 【工事管理台帳】 ・工事管理ID→主キー ・施工会社ID→主キー ・依頼ID 【工事管理明細】 ・明細ID→主キー ・工事管理ID→外部キー ・施工会社ID→外部キー ・単価 ・摘要 このような感じでしょうか。 二個の項目を主キーにした場合、スピードが非常に遅くなりませんか… >・依頼物件台帳_ID >・工事カウンター >・行番号 >の複合キーに対応する明細があるだけ。メインフォームでは、[工事カウンター]のMAX値 >を表示し、工事カウンター=1、工事カウンター=2に対応する明細を表示するのみ。 この意味がわかりません。三つの複合キーとはどういう意味でしょうか… 行番号とはなんでしょうか…
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
【補足】入力フォームサンプル ・メインフォームの[ID]は変更不可。 ・メインフォームの[依頼会社].[会社名]も変更不可。 ・サブフォームの[ID]、[依頼物件台帳_ID]は非表示。 ・サブフォームの[金額]は自動計算。 ＊テーブルに列は設けない。 ・サブフォームの[金額合計]も自動計算。 ＊テーブルに列は設けない。 先のテーブル設計ですと、こういう入力フォームの原型がウィザードで自動生成されますよ。
お礼
ありがとうございます。それは理解しています。ですが、一つの依頼で二つの違う工事が発生する場合には、テーブル設計を変えなくてはできません。一件の工事案件については上のような事例を参考にさせていただきたいと思います。
補足
ご回答ありがとうございました。 逆にお聞きしたいのですが、依頼物件一つに対して、一工事しか発生しなければ、依頼物件を登録するテーブルに、以下のようなテーブルも可能です。 【依頼テーブル】 ・依頼ID ・依頼内容 ・依頼日 【工事管理テーブル】 ・依頼ID ・工事依頼先ID ・訪問日 ・施工開始日 ・施工終了日 【工事明細テーブル】 ・施工明細ID ・依頼ID ・施工項目名 ・単価 ・数量 ・単位 しかし、一つの依頼で複数の工事が発生するのなら、上のテーブル構成でなく、私が最初にかかせていただきました構成にしなくてはいけないのではないかと、思ったのですが、その辺について何か良いアドバイスがあれば教えていただきたいです。 よろしくお願いします。
- 山田 太郎（@f_a_007）
- ベストアンサー率20% (955/4574)
テーブル[依頼物件台帳] ID 依頼会社_ID 依頼内容 テーブル[依頼物件明細] ID 依頼物件台帳_ID 行番号 項目名 単位 数量 金額 普通は、こういうテーブル設計をすると思いますよ。体裁は、一般的な売上伝票のそれです。 ID__________[1] 依頼会社_ID___[1][○○会社] 依頼内容______[〇△物件] =============================================== [01][項目名1__________][2][\1,000][\2,000] [02][項目名2__________][2][\1,000][\2,000] [03][項目名3__________][2][\1,000][\2,000] [04][項目名4__________][2][\1,000][\2,000] =============================================== [単位]を省いていますが、これが基本的な入力フォーム。
補足
ご回答ありがとうございます。 ↑の例は、依頼された工事案件に対して、工事が一件だけ発生した場合のことで、稀に、二件、つまり、違う施工会社が入ることがあるのです。その場合には、上の構造では無理があります。 ですので、私が最初に書いたようなテーブル構成にしました。
お礼
No.6に対してのお礼 どうもありがとうございました。上のご回答については、恐らく利用させて頂くかもしれませんが、親、子、孫サブというのも一応調べてみたいと思います。 あまりややこしいテーブル構成にしたくないのですが、業務上、不規則なことが起こりがちで、 また、よろしくお願いします。
補足
一応、このタイトル見つけました。 「今日だから、【帳票フォーム＋サブの構成】ｘ２（ネストはどうよ） 」 ざーっと読んだ感じですが、古いAccessだと動かない感じでしょうかね。 恐らく、フォーム構成が複雑になると負荷が高くなるのでしょうか・・・ あなたが教えて下さった方法を選びたいと思います。 ありがとうございました。