※親子リレー消去しても解決しなかった。
本記事の最後に続きを加筆。申し訳なく思う。※
メイン/サブフォームを繋ぎとめてくれていた「利用者ID」親子リンク
学習メモ3-8でサブフォームが機能しなくなった理由は、Accessの解釈と私の意図が相反していたことが原因だった。
学習メモ3-8.で実装済の構成
利用者登録(親)⇔ 利用者IDでリンク ⇔SF_新規登録(子)
Accessの解釈(検索対象者 = 登録対象者)
メインフォームのコンボボックス上で利用者を表示
↓
その利用者に属するデータをサブフォームへ登録
私が目指していたもの(検索対象者 ≠ 登録対象者)
「新規利用者がすでに登録されていないか」を確認するために
メインフォームのコンボボックス上で利用者を表示
↓
登録がないと判明した場合は
サブフォーム上で新規利用者として登録
・・・だから、メインのコンボボックスで利用者を選択しつつ
サブのテキストボックスに(メイン不在の)新規利用者を登録した瞬間に
親子リンクの思想とぶつかってしまい、Accessがフリーズした。
そもそもメイン/サブとして各フォームをリレーションさせる目的は、メインに関係する詳細情報をサブに反映させることにある。
リンクさせるフィールドには「1対多」の関係性が成立していることが前提。
設計の意図:
「新規利用者がすでに登録されていないか」を確認するために
メインのコンボボックス上で利用者を表示し、登録がなければサブフォーム上で新規利用者として登録
その設計思想をAccessに伝えるためには、
①リンク親フィールド・リンク子フィールドを消す
②①の代わりにサブフォームへ飛ぶためのボタン「新規登録」をメインに新設
Private Sub 新規登録_Click()
DoCmd.OpenForm "SF_新規登録", , , , acFormAdd
End Sub
そこではじめて
「検索対象者 ≠ 登録対象者」としたい私の意図と
Access側の設計思想が一致する。
フォーム内に別フォームを表示させるため、リレーションしないメイン/サブ運用を採用する。
複数フォームをひとつのフォームのように表示する方法としては、このほかに「タブコントロール」を用いる選択肢もある。
自作にせよ、ココナラで出品者に設計や学習アシストをお願いするにせよ、
先ずは自身が目指す構想を明確化し計画を立てることが肝要ということ。
いろいろごめんなさい。
Access爺「アンタじゃ無理!ワシが壊される前に出品者を呼んでくれ」
Errorの無限ループ
動画内で親子リンクフィールドを消去した後、エラーは消えた。
だがそれも一時的なことで、新規レコード入力後、同じエラーが起きた。
修正したくてもビュー切替すらできないロック状態→強制終了→編集→エラー...延々と続いた。
ロックがかかると慌ててしまうが、Escキーを連打すると強制解除できる。
このメイン/サブの組み合わせ課題は、学習メモ3-2.~3.4.に寄せて作ったつもりだった。
学習メモ3-2.では今回と同様に、複数テーブルを組み合わせたクエリがレコードソースとして使われていた。
メインでコンボボックスを参照し、サブで新規レコード登録を行う仕様が問題なく実現できていた。
なぜ今回はトラブルが続くのか?
理由はテーブルの構造、それを補完するために組んだクエリの構造にあった。
失敗の原因は、親子リンクフィールドではなかった。
フォームを作成するにあたり、複数テーブルを結合したクエリをレコードソースにできる。
ただ...編集できるのは、あくまで“1テーブルのみ” という制約がAccessにはある、らしい。
レコードソースの違い
学習メモ3-4
メイン:商品マスタと仕入マスタ外部キーを組み合わせた「商品情報一覧」クエリ(仕入先マスタは参照先として機能,編集先は商品マスタ)
サブ:入出庫トラン(編集先は入出庫トランザクション)
複数テーブルを結合させたクエリがレコードでも、編集対象は常に1テーブルに固定されていたから、問題が起きなかった。
今回
メイン:利用者マスタと図書利用券マスタのフィールドを組み合わせたクエリ
サブ:同上
親子リンクフィールドを削除してもメインとサブが同じクエリを参照し続ける以上、結果は変わらない。
サブのレコードをクエリからマスタテーブルに変更すると、今度は「親子リンクしてね」という種類のエラーによって阻まれる。
結局、テーブルおよびクエリの作成段階に戻り、すべての構成を見直すことになった。
それにしても時間がなさ過ぎる。今年の夏も、何ひとつ結果を残せないまま終わることになるのか...
メイン/サブ構成を中止、シンプルにひとつのフォーム内で検索と新規登録をおこなう形へと落ち着かせることができた。
また同じ失敗を繰り返さないよう次の記事に記録を残しておきたい。