アクセスとVBA、大規模でスケーラブルなアプリケーションのための最高の "アーキテクチャ"

Question

私は、Access、SQL & VBAの混在に関する最良のアプローチを知りたいと思います。 私は現在、将来進化する可能性がある大規模なアプリケーションに取り組んでいるので、私が正しいかどうかを尋ねています。

独立したVBAモジュールのSQLクエリの大部分を「ハードコード」するように選択しましたが、パラメータ（SELECT/DELETE）またはフィールド（INSERT/UPDATE）のみをパラメータとして指定します。 私が最初にやったのは、自分のフォームのコードで手続き呼び出しをして、自分のコントロールの必要な値を渡すだけで済むので便利でした。

しかし、問題は、私は新しいフィールドを追加した場合、私のテーブルの名前を変更するか、フィールドの名前を変更することで、私はそれは私が希望非常に迷惑

だ... 1によってそのテーブル1に関わるすべてのクエリを書き直す必要がありますAccessでスケーラブルなアプリケーションを使いこなすための「標準アーキテクチャ」が存在するかどうかを知る

スケーラブルとは、データベース自体とアプリケーションロジックを意味します。

Answer 1

...問題は、私は新しいフィールドを追加した場合、私のテーブルの名前を変更するか フィールドの名前を変更することで、私は1

によってその 表1に関するすべてのクエリを書き直す必要がありますIコードモジュールにSQLステートメントのテキストを保存する代わりに、QueryDefオブジェクト（保存されたクエリ）を使用することをお勧めします。

その後、後で変更されるテーブルまたはフィールド名を参照するクエリがある場合は、必ずリビジョンを必要とするクエリを手動で特定し、それらを一度に編集する必要はありません。 swapTblNamesInQueryDefs()のようなものを使うことができます。私はテーブル名のためにそれを書いたが、それもフィールド名のために働くはずである。

SQL文をコードモジュールに保存し続けると、find &と同様の処理を行うことができます。しかし、潜在的な複雑さは、置換という言葉がSQL文のテキストだけに限定されないということです。ターゲット単語があなたのVBAコードの他の場所に存在しているにもかかわらず、その単語が置き換えられることを望まない場合は、問題になります。これは、SQLがQueryDefオブジェクトにある場合には問題ありません。

新しいフィールドの追加は難しくなります。 swapTblNamesInQueryDefs()をDisplayOnlyモードで使用すると、変更されたテーブルの名前を含むクエリからSQLを調べることができます。しかし、私はどのようなクエリを修正し、必要な変更を加えるべきかを特定するための自動化可能な方法は見当たりません。