Microsoft Access 掲示板

いろいろ突っ込みどころはあるんだけど、
パッと見た感じ、「Dlookupが遅い理由をそのままに、Dlookupと同じ機能をわざわざ自前で作ろうとしている」感じですね
「なぜDLookupが遅いのか？」を理解しないと改善にはならないです

定義域集計関数とSQLの比較（T'sWare さん）

hiroton様ありがとうございます。「なぜDLookupが遅いのか？」はなんとなくレベルですが理解しました。
今回作成のモジュール概要は　Ａ：顧客テーブル　Ｂ：売上テーブル　Ｃ：締め日テーブル　Ｄ：売上明細テーブル 等があります。各テーブルにはオートナンバー型ＩＤがあります。売上毎締め日期日クエリでそれぞれ連結させて売上毎の締め日付、支払期日等を他のモジュールで算出してまして、それは問題なく機能してました（この時は処理速度も速かったです）。
Ａには顧客毎の支払条件があります（Ｃから選択）。その支払条件が変更になる場合が発生しました（例えば売上日付が2026/2/1から締め日が変更）。Ａテーブルの支払条件を改定後の内容にしてしまうと、過去の売上分も改訂された締め日になってしまうので、対策としてＥ：変更前支払条件テーブルを作成し（顧客ＩＤ、変更前の締め日ＩＤ、初期日、最終日　等のフィールド）それに変更のあった顧客分のみ変更前の支払条件を入力してます。今回作成のモジュールにＤＣｏｕｎｔでテーブルＥから対象顧客分をカウントして、それが０の場合はＡテーブルからから、1以上ならＥテーブルから締め日ＩＤを抽出しました。今後同一顧客で２回以上の変更もあるかもを想定して売上日付をＥテーブルの初期日、最終日の期間内かどうかも判定させて条件に合う締め日ＩＤを抽出させてます。このモジュールを売上毎締め日期日クエリに組み込み実行すると結構時間かかるので、Ｄｌｏｏｋで締め日ＩＤを抽出が原因？でしたのでＳＱＬでしたらと思ったのです。
このモジュールでいくつかの値（支払条件テキスト、締め実日等）も同じパターンで値を抽出しているのも遅い原因と思いますが。
この方法が良くないでしょうか？

良いか悪いかだと、うーん、ちょっとだけ、よくないですかねぇ
Eのテーブルは、変更があったものだけ、ではなく、履歴としてすべてを記録するようにすると余計な存在有無チェックがなくなるのでいろいろとはかどります（Dlookupを使うにせよ、SQLで全部やるにせよ高速化になります）

特定日のデータを期間の設定（開始日、終了日）から見つけ出す作業は、ACCESSでは特に苦手とする部類だと思います。モジュール化して対応しようとすると、どうしても「DLookupは遅い」のボトルネックに引っかかる形になるので、SQLを駆使してクエリ一つに書き上げるというのが一般的な回答になるんじゃないでしょうか？（SQLを直接記述するんでそもそもACCESSレベルでは一般的ではない）

遅い早いに関しては個人の感覚によるところなので、実際に運用する件数n件に対して、処理時間yでそれが、実運用に耐える/耐えない時間であるという評価基準が必要になります
それによって、手法のシンプルさ（メンテナンス性）と実処理時間のバランスが取れるように、最適な回答が変わってくるでしょう

自分はSQLゴリゴリ書くのはあまり得意ではないので、そっちの方向は他の人に任せます（お願いします）
VBAの話をするのであれば、まずは質問にあるところで、

このモジュールでいくつかの値（支払条件テキスト、締め実日等）も同じパターンで値を抽出している

これは、遅くなる原因としてかなりの比重がありそうです

Dlookup("ID")
Dlookup("支払条件テキスト")
Dlookup("締め実日等")

Set dbs = CurrentDb
Set rs = dbs.OpenRecordset("～")
id = rs!ID
支払条件 = rs!支払条件テキスト
締め実日 = rs!締め実日
rs.Close

上記Dlookupだけで処理した場合はDlookupのボトルネック＋検索捜査が3回発生するのに対し、下記、レコードセットを取得した処理では、ボトルネック部分が1回、捜査処理も1回でそのほかのデータ取得は一瞬で終わります
先に挙げたリンク先でも、こういう処理をしたいならSQL文を使ったほうが良いと言っていますね
特に、一つのレコードから複数のフィールドの値を参照したいのであればDlookupの出番はないです

もう少し、VBAの高度な話をすると、

Set dbs = CurrentDb

これにかかる時間が相当にありそうだ、と、先に挙げたリンク先に指摘があります。オリジナル関数の呼び出し事（実処理のレコード数分だけ）実行しているとこれもボトルネックになるので、これをやらないように組むということもできます

オリジナル関数の外で変数を用意しておく

Public dbs As Database
Public rs As Recordset

Sub Init()
  Set dbs = CurrentDb
End Sub

Function オリジナル関数()
  Set rs = dbs.OpenRecordset("～")

Init関数を事前にどこかで1度だけ呼び出して、「ボトルネックになるDatabaseオブジェクトの生成」を1回のみにするなんて方法も考えられるでしょう

先に挙げたように、許容点はどこか？という話になるので、詳しい解説は抜きにしてひとまずこのくらいにしておきます

リレーション先の値に更新があった場合、過去の値も変更されてしまう場合の対処法ということですよね。

いろいろな方法があると思いますが、自分は下記のような設計にすることが多いです。

締日の更新に対処する場合の例

Ａ：顧客テーブル　Ｂ：売上テーブル　Ｃ：締め日テーブル

このようなテーブル構成の場合、締め日IDはＡではなくＢに格納します。
Ｂの入力時に規定値として最新の対応する締め日IDを入力します。
これは規定値プロパティを使うか、入力フォームの更新後処理で入力します。

この方法だとクエリで単純にリンクさせるだけで対応する締日を取得できます。

hiroton様ありがとうございます。色々とハイレベルなテクニックがありますね。レコードセットが今ひとつ理解できていません（どういうものなのか・・・）。使いこなせれば大変便利とは思っています。イメージとしてはプロシージャ内でテーブルの様なものを作成しておき（それがレコードセット？）、それに対して代入や更新等が可能という感じでしょうか？　何かで聞いた事があるのですがレコードソースのあるフォームであれば自動的にレコードセットが出来ているのでしょうか？
初歩的な事ですみません。

hatena様ありがとうございます。なるほど売上毎に持たせるといいですね（1レコードづつオートナンバーでユニークになっていますので）。売上テーブルにフィールド追加して過去の分は引っ張り出せるのでそれで代入しておき、新規レコードにはフォーム等で仕組み作る形で。
それが一番楽に出来る様な気がします、試してみます。
アイデア大変参考になりました。

その支払条件が変更になる場合が発生しました…過去の売上分も改訂された締め日になってしまうので、

　正規化崩し云々以前に、正規化が杜撰だったと気づいてどうしよう？というだけでしょ。設計から全部やり直しましょう。

hatena様ありがとうございます。アドバイス頂いた方法で試し正常動作することが確認出来ました。この方法であれば売上毎に可変可能ですのでイレギュラーな事案にも対応出来ます。後は入力フォームの工夫だけです。助かりました。

hiroton様ありがとうございます。フォームを使っての処理がほとんどなのでレコードセットは色々試してみます。

事前に色々想定しているのですが、どうしても想定外の事案が発生しますのでその都度改訂が必用になります。その時のアプローチが重要ですね。大変勉強になりました。