2004年09月14日
レポートでパラメータクエリを使う
通常クエリといえば、テーブルの中から項目を選択することである。
選択する条件は SQL 文の WHERE 句に記述する。
ところが、クエリをアプリケーションに組込む場合、
選択条件が実行時まで決まらない時がある。
そんな時便利なのがパラメータクエリだ。
Access なら
WHERE 項目 = []
と記述する。
ちなみに JDBC なら
WHERE 項目 = ?
とする。
Access の場合は実行時になっても条件が決まらない場合はダイアログボックスで入力を促される。(JDBC では確かエラーになったはず。今度検証してみます。)
一方、レポートとは、値の変更できないフォームと思って差し支えない。
値が変更できないから、VBA を使ってテキストボックスに値を設定するなんていう芸当はできない。
全て事前にレポート設計時に組込んでおかなければならない。
フォームなら VBA でパラメータを設定できるがレポートだとそうもいかない。
選択する条件は SQL 文の WHERE 句に記述する。
ところが、クエリをアプリケーションに組込む場合、
選択条件が実行時まで決まらない時がある。
そんな時便利なのがパラメータクエリだ。
Access なら
WHERE 項目 = []
と記述する。
ちなみに JDBC なら
WHERE 項目 = ?
とする。
Access の場合は実行時になっても条件が決まらない場合はダイアログボックスで入力を促される。(JDBC では確かエラーになったはず。今度検証してみます。)
一方、レポートとは、値の変更できないフォームと思って差し支えない。
値が変更できないから、VBA を使ってテキストボックスに値を設定するなんていう芸当はできない。
全て事前にレポート設計時に組込んでおかなければならない。
フォームなら VBA でパラメータを設定できるがレポートだとそうもいかない。
これについてはベテランにも質問を投げてみたが解決できなかった。
いろいろ苦心して姑息な手段を考え始めていたのだが、
辿り着いたのは意外と正攻法だった。
それは、まずレポート全体のプロパティでデータソースとなるテーブルもしくはクエリを指定する。
既存のもので適当なものが存在しなければクエリビルダでその場で作ってしまってもいい。
ちなみにここで指定するものはパラメータを含まない、すなわち条件で絞り込まないものが良い。
そしてパラメータとなる条件式(SQL なら WHERE 句で記述する条件の内、動的に決まるもの)をフィルターとして設定すればよいだけ。
動的に…と言っているくらいだから、直接レポートを開くことはないだろう。
その前にフォームが用意してあって、その中のどこかにパラメータの値が埋め込まれているはずだ。
そしてレポートを表示(もしくは印刷)するコマンドボタンを押下した時に、
Dim myFilter As Variant
myFilter = <条件式(文字列)>
DoCmd.OpenReport [レポート名], [開き方], myFilter
のようなコードが実行されれば、見事条件が絞り込まれ、パラメータクエリを使ったのと同等の効果が得られるというわけだ。
ちなみに、FilterOn プロパティを True にしておく必要がある。
いろいろ苦心して姑息な手段を考え始めていたのだが、
辿り着いたのは意外と正攻法だった。
それは、まずレポート全体のプロパティでデータソースとなるテーブルもしくはクエリを指定する。
既存のもので適当なものが存在しなければクエリビルダでその場で作ってしまってもいい。
ちなみにここで指定するものはパラメータを含まない、すなわち条件で絞り込まないものが良い。
そしてパラメータとなる条件式(SQL なら WHERE 句で記述する条件の内、動的に決まるもの)をフィルターとして設定すればよいだけ。
動的に…と言っているくらいだから、直接レポートを開くことはないだろう。
その前にフォームが用意してあって、その中のどこかにパラメータの値が埋め込まれているはずだ。
そしてレポートを表示(もしくは印刷)するコマンドボタンを押下した時に、
Dim myFilter As Variant
myFilter = <条件式(文字列)>
DoCmd.OpenReport [レポート名], [開き方], myFilter
のようなコードが実行されれば、見事条件が絞り込まれ、パラメータクエリを使ったのと同等の効果が得られるというわけだ。
ちなみに、FilterOn プロパティを True にしておく必要がある。