リリース12
E06048-01
目次
前へ
次へ
| Oracle Applications開発者ガイド リリース12 E06048-01 | 目次 | 前へ | 次へ |
問合せ検索（ビュー検索とも呼ばれます）を実装するには2つの方法があります。1つは行の値リストを表示する方法で、使用できる行を表示してそこから1つを選択できます。もう1つは、ユーザーがデータ選択に使用するフィールドを示す「検索」ウィンドウを開く方法です。
指定したブロックに適用できる実装方法は1つのみです。フォーム内にある問合せ可能なブロックのすべては、問合せ検索をサポートしている必要があります。『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』は、2つの実装について、どのような場合により適切であるかを説明しています。
フォームに入ると同時に行の値リストまたは「検索」ウィンドウを表示する場合には、WHEN-NEW-FORM- INSTANCEトリガーの終わりに次のファンクションをコールします。
EXECUTE_TRIGGER('QUERY_FIND'); これによって、フォームの最初のブロックにある間にユーザーがファンクションを起動することをシミュレートします。
行の値リストを実装するには、まずフォーム・パラメータとしてユーザーが必要とする行の主キーを選択する値リストを作成し、次に問合せを実行する直前の結果ブロック内の主キー・フィールドに値をコピーします。
ここでは、DEPTブロックを例としてあげます。DEPTブロックはDEPT表に基づき、DEPTNO、DNAMEおよびLOCの3つの列で構成されています。この表の各行は会社の部門に対応しています。
行の値リストに対して主キーを持つフォーム・パラメータを作成します。行の値リストが詳細ブロック向けの場合は、マスター・ブロック（結合列）に対する外部キー向けのパラメータは必要ありません。ただし、後の手順でレコード・グループのWHERE句の中にその列を含む必要があります。適切なデータ型とデータ長を設定してください。
たとえば、DEPTブロックに対しては、DEPTNO_QFと呼ばれるパラメータを作成します。
要求された行についてユーザーによる識別が必要な列を含む値リストを作成します。行の値リストが詳細ブロック向けの場合は、レコード・グループのWHERE句の中にマスター・ブロック（結合列）に対する外部キーを含める必要があります。列に対する主キーをパラメータに返します。
ここでは、例としてDEPTNO列およびDNAME列を含む値リストとDEPT_QFを作成します。DEPTNOの戻り項目をパラメータDEPTNO_QFに設定します。ユーザーはDNAMEは見ることができますが、これはどのフィールドにも返されません。
次のコードを含むブロック・レベルのPRE-QUERYトリガーを作成します。（実行階層: 前）
IF :parameter.G_query_find = 'TRUE' THEN
<Primary Key> := :parameter.<Your parameter>;
:parameter.G_query_find := 'FALSE';
END IF;
複数部分に分割されたキーについては、主キーに対して複数の割当てを必要とします。
パラメータG_query_findは、TEMPLATEフォーム内にあります。
Deptの例では、PRE-QUERYトリガーは次のコードを含んでいます。
IF :parameter.G_query_find = 'TRUE' THEN
:DEPT.DEPTNO := :parameter.DEPTNO_QF
:parameter.G_query_find := 'FALSE';
END IF;
最後に、次のコードを含む結果ブロック（実行階層: オーバーライド）にブロック・レベルのユーザーが名前を付けたトリガーQUERY_FINDを作成します。
APP_FIND.QUERY_FIND('<Your LOV Name>');
DEPTに対しては次のとおりです。
APP_FIND.QUERY_FIND('DEPT_QF');
「検索」ウィンドウを実装するには、検索を開始してすべての項目値をそのブロックから問合せを実行する直前の結果ブロックにコピーするまで、ユーザーが検索するフィールドを含む別のウィンドウを作成します。
この例として、EMP表に基づくブロックの例があります。これは結果ブロックとして参照されます。この表の主キーはEMPNOです。このブロックには、データ・フィールド、HIREDATEも含まれています。「検索」ウィンドウは、EMPNOまたはHIREDATESの範囲によってレコードを検索するように設計されています。
「検索」ウィンドウのルック・アンド・フィールの詳細は、『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』を参照してください。
「検索」ウィンドウのフレックスフィールドには特別な処理が必要です。詳細は、「「検索」ウィンドウでのキー・フレックスフィールドの使用」を参照してください。
APPSTANDフォームから作成中のフォームへQUERY_FINDオブジェクト・グループをコピーします。これには、「検索」ウィンドウ作成時の最初のウィンドウ、ブロックおよびキャンバスが含まれています。
コピーを終了したらこのオブジェクト・グループを削除してください。ウィンドウ、キャンバスおよびブロックは残りますが、別の「検索」ウィンドウが必要な場合に再度このオブジェクト・グループをコピーすることが可能です。
警告: このオブジェクト・グループは参照しないでください。カスタマイズが必要です。
ブロック名、キャンバス名およびウィンドウ名を変更します。ブロックの問合せ可能なプロパティを「No」に設定します。
この例では、ブロック名、キャンバス名、ウィンドウ名をそれぞれEMP_QF、EMP_QF_CANVAS、EMP_QF_WINDOWに変更します。
結果ブロック名が引数となるように、「検索」ウィンドウ・ブロックの「新規」ボタンに対してWHEN-BUTTON-PRESSEDトリガーを編集します。Oracle Applicationsは、この情報を使用して作成したブロックにナビゲートしたり新しいレコードの位置に移動できます。このボタンが含まれているのは、最初にフォームを開いたときに「検索」ウィンドウが自動的に表示されるためです。ユーザーが新しいレコードの入力をすぐに行う場合には、このボタンを押すことで実行できます。
app_find.new('<Your results blockname here>');これは次のようになります。
app_find.new('EMP');結果ブロック名が引数となるように、「検索」ボタンに対してWHEN-BUTTON-PRESSEDトリガーを編集します。この情報によって、Oracle Applicationsでブロックにナビゲートしたり問合せを実行することが可能になります。
app_find.find('<Your results blockname here>');これは次のようになります。
app_find.find('EMP') 「検索」ウィンドウにある項目についてさらに検証する必要がある場合は、APP_FIND.FINDのコール前に作成したコードを置きます。特に、最大/最小範囲のフィールドが正しいことを確認する必要があります。また、条件が何も入力されていない場合や入力された条件の処理に長時間を要する場合には、警告を発することもできます。
「検索」ブロックの「前のナビゲーション・データ・ブロック」プロパティが結果ブロックとなるように設定します。これによって、ユーザーは問合せを実行せずに「検索」ウィンドウから離れることができます。
次のデータ・ブロックおよび前のデータ・ブロックは、結果ブロックから上下のオブジェクト階層にのみ移動します。すなわち「検索」ウィンドウに戻ることはありません。
「検索」ボタンと同一の機能を持つように「検索」ブロックのKEY-NXTBLKトリガーを編集します。ユーザーが「実行」->「次のブロック」と選択した場合は、「検索」ボタンを押したのと同じ動作となります。
「検索」ウィンドウのタイトルを変更します。
EMPの例では「従業員の検索」を使用します。
ユーザーが「検索」ウィンドウ・ブロックで問合せを行うための項目を作成します。結果ブロックから「検索」ウィンドウ・ブロックにコピーをすることで簡単に作成できます。
「検索」ウィンドウの項目については次のガイドラインに従ってください。
必須プロパティを「No」に設定します。
デフォルト値をNULLに設定します。
結果ブロックの項目をコピーした場合には、新しい項目すべてのデータベース項目に「No」が設定されていることを確認し、関連付けられているトリガーをすべて削除てください（特に検証トリガー）。ある理由によって特定のトリガーをそのままにしておく必要があると判断した場合には、トリガーが参照するフィールドを「検索」ブロックを示すように必ず変更してください。
通常、「検索」ウィンドウ・ブロックの項目には値リストが関連付けられています。これは、ユーザーがその項目に対して有効な値を正確に選択できるようにするためです。この値リストは、現在有効な値だけでなく、有効な値すべてを示す必要があります。日付フィールドでは、カレンダに関連したKEY-LISTVALトリガーを使用する場合もあります。
項目に表示値および関連付けられたIDフィールドがある場合は、「検索」ウィンドウ・ブロックには両方が必要です。IDフィールドは、問合せを実行させてパフォーマンスを向上させるのに必要です。
項目が、結果ブロックにあるチェック・ボックスやオプション・グループである場合は、「検索」ウィンドウ・ブロックのポップリストである必要があります。項目がNULLの場合は、問合せに制限はありません。
「検索」ウィンドウを用途にあわせて調整します。ウィンドウ、位置、フィールドなどのサイズを変更します。
結果ブロック（実行階層: 前）でブロック・レベルのPre-Queryトリガーを作成します。ここでは、「検索」ウィンドウ・ブロックから（問合せが実際に生じる）結果ブロックに問合せ基準をコピーします。
文字データのコピーには、Oracle FormsのCOPYビルトインを使用できます。その他のデータ型に対しては「:=」を使用して値を直接代入できますが、その場合ユーザーはワイルドカードを使用できません。ただし、「検索」ウィンドウの項目の多くは、一意の値を提供するように値リストを使用しているため、ワイルドカードが必要となることありません。
IF :parameter.G_query_find = 'TRUE' THEN
COPY (<find Window field>,'<results field>');
:parameter.G_query_find := 'FALSE';
END IF; よく使用される特別な条件の例に、数値、日付、文字の範囲の問合せがあります。APP_FIND.QUERY_RANGEプロシージャは、問合せロジックを確認するために定義されています。最初の2つの引数として最小値と最大値が渡され、3番目の引数として実際に問合せが実行されるデータベース・フィールドの名前が渡されます。
EMPの例は次のとおりです。
IF :parameter.G_query_find = 'TRUE' THEN
COPY(:EMP_QF.EMPNO, 'EMP.EMPNO');
APP_FIND.QUERY_RANGE(:EMP_QF.Hiredate_from,
:EMP_QF.Hiredate_to,
'EMP.Hiredate');
:parameter.G_query_find := 'FALSE';
END IF;実表フィールドの問合せ長（結果ブロック内）は、問合せ基準を満たすように十分長くする必要があります。そうなっていない場合には、フィールドに対して値が長すぎるというエラーとなります。すべてのフィールドには、少なくとも255の問合せ長が必要です。
結果ブロックのデータベース・フィールドに基づくラジオ・グループ、リスト項目、チェック・ボックスがあり、それらがNULLでない場合には、「検索」ウィンドウからこれらの値をコピーするだけでかまいません。
デフォルトのWHERE句を調節する必要が生じた場合、非問合せ検索の問合せの実行時には忘れずに設定を元に戻してください。
次のコードを含む結果ブロックに（実行階層: オーバーライド）ブロック・レベルのユーザーが名前を付けたトリガーQUERY_FINDを作成します。
APP_FIND.QUERY_FIND('<results block window>',
'<Find window>',
'<Find window block>'); EMPの例は次のとおりです。
APP_FIND.QUERY_FIND('EMP_WINDOW', 'EMP_QF_WINDOW',
'EMP_QF');