• ベストアンサー

複雑なクエリ(ビュー)を元にしたフォームでデータの追加・更新・削除をしたい

Accessでは、単純な内部結合のクエリを元にフォームを作った時、データの追加・更新・削除ができますよね? そして、外部結合や選択クエリが混ざってくるとできなくなりますよね? いろいろな本を漁ったのですが、そのような場合、フォームを非連結にしてVBAでがりがり処理する事になってしまっています。 やはりVBAを使わないといけないのでしょうか? どうせVBAを使わないといけないというのなら、出来れば汎用性の高いオブジェクトにしてしまいたいのですが、スキルがありません。(笑) 何とぞアドバイスを。

質問者が選んだベストアンサー

  • ベストアンサー
  • selenity
  • ベストアンサー率41% (324/772)
回答No.1

汎用性の高いオブジェクトにするには 初期設計がすべてでしょう。 項目名、テーブルの正規化、など、、、 もともとリレーショナルデータベースでは テーブル同士が1対多で結合する場合が大半です。 ですから「多」側のレコードが操作される場合は 「多」の中のどのレコードが操作されたかを [フォーム].[レコードソース]から判断するには 情報不足になっている場合がほとんどだからです。 つまり、[フォーム].[レコードソース]として指定した SQL文ないしはクエリーがすでに情報不足な状態に なっているのです。 VBAを使うしかないでしょう。

marsah
質問者

お礼

ご回答ありがとうございます。 やはり避けて通れませんか… Access2000の仕様として無理なのですね… ところで、 「Access2000+MSDEによる仕入買掛システムの構築」山田健一 著、技術評論社 刊 と言う本のサンプルプログラムに、 “レコードセットに含まれる全てのフィールドに対し、テーブルフィールド名と等しく名付けられたコントロールのフォーム変数に値を代入する。(前提としてフォーム中に全てのフィールド名と同名のコントロールが存在しなければならない。)” というような仕様のサブプロシ-ジャ例が載っているのですが、アルゴリズムとしてはこれがベストなのでしょうか? もしよろしければご見解を伺いたく存じます。 以上、ありがとうございました。

marsah
質問者

補足

その後、読書したり講習会に出たりしまして、いろいろと考えが変わりました。 汎用性の高いオブジェクトを設計するくらいなら、Accessの中でやるよりもむしろAccessを部品として使った方が良さそうですね。(笑) ありがとうございました。

関連するQ&A