Access アプリケーションの起動時には、ユーザーに可能な限り最高のエクスペリエンスを提供するために実行する必要があるアクションがあります。 オブジェクト名は、Northwind 2.0 Starter Edition データベースで容易に調べることができるように提供されています。
AutoExec マクロの使用
Access アプリケーションを開いてアプリケーションを初期化するときに、 AutoExec マクロ が実行されます。 Access には、起動時に開くフォームの名前のデータベース設定も用意されています。 このファイルは、こちらから入手できます。
ファイル>オプション>現在のデータベース>アプリケーション オプション>表示フォーム
開始フォームを識別できる場合は、AutoExecマクロの代わりにそれを使用してみませんか? その理由は、コンテンツを有効にする必要がある信頼できる場所にあります。
AutoExec マクロ (このマクロの名前は Autoexec にする必要があります) は、信頼できる場所のセキュリティ警告が発生したときに実行できる唯一のコードであり、警告を適切に処理できます。 推奨される方法は、アプリケーションが正しく実行されるように、すべてのエラーと警告を処理することです。 これは、多くの場合、防御的プログラミングと呼ばれます。 起動時に AutoExec マクロを使用することが最善の防御策です。 信頼できる場所の詳細については、「 Northwind 2.0 Starter Edition: VBA の簡単な概要」を参照してください。
スタートアップ モジュールの目的
AutoExec マクロは、データベースが信頼できる場所にあると判断すると、StartUp と呼ばれる modStartUp 内の Visual Basic for Applications (VBA) 関数を呼び出します。 このモジュールでは、ユーザーに可能な限り最適なエクスペリエンスを提供するために実行する必要があるイベントを決定します。 これらのアクティビティは、スタートアップ モジュールによって次の順序で実行されます。
- clsErrorHandler からグローバル エラー ハンドラーをインスタンス化します。
- アプリケーション タイトルを設定します。 詳細については、Application.AppTitle プロパティを参照してください。
- ナビゲーション ウィンドウが表示されていて、正しいカテゴリに設定されていることを確認します。
- 必要に応じて frmWelcome 画面を表示します。
- Windows ユーザー ID を取得し、自分が Employee テーブルに含まれているかどうかを確認します。 詳細については、「 環境関数 」と「 DLookup 関数」を参照してください。
- ユーザーが Employee テーブルにいない場合は、frmCredentials を開いて名、姓、役職を入力できるようにします。
- ユーザーが Employees テーブルにいる場合は、frmLogin を開き、[Employee] コンボ ボックスで自分の名前を選択します。 リストから好きなユーザーを選択できます。
frmWelcome フォームの目的
frmWelcome は、アプリケーションを初めて開いたときに表示されます。 このフォームには、アプリケーション内を移動する方法、レイアウト方法、トピックに関する詳細情報を取得する方法が表示されます。
フォームの下部に、"データベースが開かれたときにこのフォームを表示する" というチェック ボックスがあります。 このチェックを外すと、データベースを再度開いたときに表示されなくなります。 この設定は、テーブル SystemSettings に保持されます。
frmCredentials フォームの目的
エクスペリエンスをパーソナライズするために、データベースは役職と一緒に名と姓を入力するように求めます。 それが完了したら、[自分 の追加 ] をクリックして Employees テーブルに追加し、frmMainMenu を開きます。
"従業員" テーブルに追加される理由 その理由の 1 つは、テーブルに監査データ マクロがあることです。 これらのマクロは、レコードを追加または変更したユーザーと日時をキャプチャします。 これらのフィールドでは、アクションの影響をテーブルで確認できます。 詳細については、「 データ マクロを作成する 」および 「データ マクロ イベント」を参照してください。
frmLogin フォームの目的
本番アプリケーションでは、セキュリティ上の理由から自分としてしかログインできません。 ただし、選択した従業員としてログインすることは許可されています。 なぜそんなことをしているのでしょうか?
開発者は、別の視点からアプリケーションをテストまたは体験できる必要がある場合があります。 ユーザーは、さまざまな権限 (実行と表示が許可されていること、または実行しないことと表示しないこと) を持つ場合があります。 人事部門について考えてみましょう。 その部門には 15 人の従業員がいる可能性があります。 おそらく、15 人が入力したり、給与を変更したりすることは望ましくありません。 organization には、給与を変更できる 1 人のユーザーと、それを承認する 2 人目のユーザーがいる場合があります。 開発環境では、設定したコントロール (誰が何ができるか) が機能しているかどうかをテストする必要があります。