非営利組織のAccessデータベースをサポートしています。データが不思議に変化しているという問題があり、これがコンピューターの知識がほとんどないユーザーが原因なのか、私のバックグラウンド処理が原因なのかについて、親しみやすい議論が交わされました。
これらの条件について、UIレベルでいくつかのチェックを追加しましたが、特定のフィールドが変更されたときにログを記録するために、データベーステーブルレベルでいくつかのチェックを行いたいと思います。このようにして、変更がユーザーによって開始されたのか、バックグラウンドで実行されている更新クエリから開始されたのかを知ることができます。通常はon updateトリガーを使用しますが、私の知る限り、Accessはトリガーをサポートしていません。Accessで利用できる他のロギングまたはトリガーのような機能はありますか？
回答:
残念ながら、Microsoft Accessにはトリガー、またはトリガーに似たものはありません。私の頭の上には、魅力的な選択肢がいくつかあります。
DateModifiedし、UserModified列、およびこれらの値を含めるようにコードを更新。欠点は、レコードを更新した最後の人物のみを知ることができ、見る履歴がないことです。LittleBobbyTablesメソッドに加えて、3番目のオプションがあります。これには、_audit通常のテーブルごとにテーブルを作成し、それらをサポートするためのロッタロジック全体を記述して、物事が変更されたときにレコードをそれらのテーブルに挿入します。（レコードをいつ保存/更新/削除するか知っていますか？）
確かに、これは「より大きなデータベース」が行う方法です。ここでの欠点は、サーバーでトリガータイプの作業をシミュレートするために手動で実行する必要がある多くのロジックです。
たとえば、SQL Server Expressは無料であり、Accessの代替品になる可能性があることに注意してください。これにより、必要な監査機能が提供されます。「監査テーブル」アプローチは実行可能ではないと思います。これは、データベースに接続するすべてのユーザーが、そのロジックが組み込まれている「公式」クライアントを介して接続することを前提としています。トリガーを使用すると、ランダムクライアントから起動しないとデータにアクセスできません。
3番目のオプションは、Wiresharkまたは類似のクライアントとデータベースの間のトラフィックを実際に監視することです（これは実際にはTDSではなく、ファイル共有プロトコルであると思いますか？）、だれが何を、いつ、どのマシンから行うかを正確に確認できます。これの欠点は、大量のストレージと分析を行うためのスクリプトが必要であり、パフォーマンスに影響を与える可能性があることです。