他の質問で得た助けといくつかの優れたチュートリアルのおかげで、ライブラリに本を保持するためのアクセス データベースを作成でき、データベースに新しい本を入力するための適切なフォーム (いくつかのサブフォームを含む) ができました。(全てaccess 2003のみによる)。
次のステップは、DB にクエリを実行して書籍を検索できるようにすることです。
私は次のアプローチを取ることを検討していましたが、それが実現可能かどうか、および/またはその努力が法外なものになるかどうかはわかりません. 実際、私はすでに自分自身の懸念や疑問符を持っています。
私のアプローチについてあなたの意見を共有し、最終的に私の懸念のいくつかに対処していただけますか? (私の懸念に対処する他の質問やリソースへのリンクはまったく問題ありません!)
ご協力いただきありがとうございます!
ポイント1. さまざまな種類のクエリ (作成者別、タイトル別など) を実行するためのボタンを含むコントロール フォームを作成します。また、データベース全体に対する「フリー テキスト検索」オプションも用意したいと考えています。このフォームには、たとえば著者による検索のための著者などの検索条件を入力するためのフィールドも含まれます。これらのフィールドは、ユーザーが検索しやすいようにオートコンプリート付きのコンボ ボックスにする必要があります。
ポイント２．実行されるさまざまなクエリは、対応するボタンのクリック イベントの vba コードに「ハードコード」されます。これは、特に他のフィールドからパラメーターを渡す必要がある場合に、手動で SQL クエリを作成する方が簡単だと思うためです。さらに、コードに「保存」できる場合、フォームを増やしてクエリをDBに個別に保存する必要はないと思います。
ポイント3. クエリの最終結果 (レコード セット?) がフォームに表示されます。実行されるクエリに関係なく、出力する同じフィールドを常に選択するため、1 つのフォームがすべての異なるクエリの出力として使用されます。この理由から、フォームの外観と動作を完全にカスタマイズできるフォームが必要です。可能であれば、フォームはデータシート型にする必要があります (ただし、これは厳密な要件ではありません)。検索条件の違いを考えると、クエリ結果が揮発性のテーブル/レコード セットに格納されていてもまったく問題はなく、リクエストごとに再入力する必要があることは問題ではないと思います。
ポイント1の懸念事項。フリーテキスト検索は本当に実現可能ですか? どうすればこれを行うことができますか?
ポイント2の懸念事項. すべての入力パラメーターを使用して SQL クエリを保持する文字列を作成するのは簡単ですが、クエリを実行するにはどうすればよいでしょうか? チュートリアルでの検索で混乱し、これを行う方法がわかりません。前述のように、クエリを個別に保存してクエリ コレクション内の特定のクエリを参照するのではなく、"SQL 文字列" を実行します。これはどのように行われますか？また、結果を変数に格納するにはどうすればよいですか? Recordset は、一時テーブルを格納するための適切な変数の型ですか?
ポイント3の懸念事項. 「出力」フォームを作成するにはどうすればよいですか? フィールドを (デザイン ビューで) 非バインドとして作成するか、データベースのテーブルにバインドしますか? また、フォームに変数のデータを入力するにはどうすればよいですか? データベースに複数の多対多の関係があることを考えると、データシートは実行可能ですか (著者や書籍など)。もう一度フォームとサブフォームを作成する必要がある場合、「テーブル」が設計中に存在せず、「実行時」にのみ存在する場合、サブフォームとメイン フォームを接続するにはどうすればよいですか? また、前述のように、これらは異なり、vba コードでハードコードされているため、クエリもありません。
PS情報については、これはすべて「趣味」として行われ、それを行うことで何か新しいこと（アクセスとvba）を学ぶために...
1 に答える
ポイント 1. さまざまな種類のクエリ (作成者別、タイトル別など) を実行するためのボタンを含むコントロール フォームを作成します。また、データベース全体に対する「フリー テキスト検索」オプションも用意したいと考えています。このフォームには、たとえば著者による検索のための著者などの検索条件を入力するためのフィールドも含まれます。これらのフィールドは、ユーザーが検索しやすいようにオートコンプリート付きのコンボ ボックスにする必要があります。
確かに、ドロップダウンを使用してフォームに入力できます。そのためのウィザードがあります。ドロップダウンを使用してどこでも検索することはできませんが、便利な検索ボタンがあるか、連結して InStr を使用できます。
ポイント 2. 実行されるさまざまなクエリは、対応するボタンのクリック イベントの vba コードに「ハードコード」されます。これは、特に他のフィールドからパラメーターを渡す必要がある場合に、手動で SQL クエリを作成する方が簡単だと思うためです。さらに、コードに「保存」できる場合、フォームを増やしてクエリをDBに個別に保存する必要はないと思います。
accdes/mdes の作成を開始すると、クエリをコードから除外するポイントがわかります。
ポイント 3. クエリの最終結果 (レコード セット?) がフォームに表示されます。実行されるクエリに関係なく、出力する同じフィールドを常に選択するため、1 つのフォームがすべての異なるクエリの出力として使用されます。このため、フォームの外観と動作を完全にカスタマイズできるフォームが必要です。可能であれば、フォームはデータシート型にする必要があります (ただし、これは厳密な要件ではありません)。検索条件の違いを考えると、クエリ結果が揮発性のテーブル/レコード セットに格納されていてもまったく問題はなく、リクエストごとに再入力する必要があることは問題ではないと思います。
再増殖すると肥大化する可能性があります。可能であれば、MS Access の一時テーブルは常に避けてください。