ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Reportsレポート作成のためのユーザーズ・ガイド
11gリリース1(11.1.1)
B61376-01
  ドキュメント・ライブラリへ
ライブラリ
製品リストへ
製品
目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

2.6 PL/SQL

この項の各トピックでは、Oracle Reports BuilderにおけるPL/SQLの使用について説明します。

2.6.1 PL/SQLエディタについて

PL/SQLエディタを使用すると、PL/SQLプログラム・ユニットを作成し、編集できます。

使用に関する注意

プログラム・ユニットを変更すると、依存するプログラム・ユニットのコンパイル済のステータスが失われ、オブジェクト・ナビゲータの「プログラム・ユニット」ノードの下にある名前の後にアスタリスク(*)が表示されます。「名前」リストを使用して、PL/SQLエディタで直接これらのプログラム・ユニットにナビゲートし、再コンパイルできます。

制限

  • PL/SQLパッケージ、ファンクションまたはプロシージャを削除する場合は、レポート内の参照もすべて削除する必要があります。参照を削除しないと、レポートをコンパイル、生成または実行するときにエラーが発生します。

  • PL/SQLパッケージ、ファンクションおよびプロシージャの名前は、レポート内で一意にする必要があります。列、グループ、問合せまたは印刷可能なオブジェクトの名前と重複しないようにしてください。

関連項目

第4.13.2.3.1項「PL/SQLエディタの編集機能」

2.6.2 ストアドPL/SQLエディタについて

ストアドPL/SQLエディタを使用すると、データベースでストアドPL/SQLプログラム・ユニットを作成し、編集できます(データベースは、オブジェクト・ナビゲータの「データベース・オブジェクト」ノードの下に表示されます)。

関連項目

第4.13.3.2項「ストアド・プログラム・ユニットの作成」

2.6.3 構文パレットについて

構文パレットは、PL/SQLの言語要素やビルトイン・パッケージの構成メンバーを、PL/SQLエディタやストアドPL/SQLエディタに表示して、コピーできるようにするプログラミング・ツールです。

関連項目

第4.13.2.4項「PL/SQLエディタへの構文の挿入」

2.6.4 プログラム・ユニットについて

プログラム・ユニットは、現行のレポート内でPL/SQLから参照できるパッケージ、ファンクションまたはプロシージャです。


注意:

プログラム・ユニットは、他のレポートから参照できません。複数のレポートから参照できるパッケージ、ファンクションまたはプロシージャを作成する場合は、外部PL/SQLライブラリを作成します(第4.13.5.1項「外部PL/SQLライブラリの作成」を参照)。

レポートでのPL/SQLの使用に関する詳細な例は、第40章「PL/SQLを含むレポートの作成」を参照してください。

制限

  • PL/SQLパッケージ、ファンクションまたはプロシージャを削除する場合は、レポート内の参照もすべて削除する必要があります。参照を削除しないと、レポートをコンパイル、生成または実行するときにエラーが発生します。

  • PL/SQLパッケージ、ファンクションおよびプロシージャの名前は、レポート内で一意にする必要があります。列、グループ、問合せまたは印刷可能なオブジェクトの名前と重複しないようにしてください。

例: 式におけるPL/SQLファンクションの参照

次のようなグループと列を含むレポートがあるとします。

Groups    Columns         Summary 
-----------------------------------------
RGN       REGION
          RGNSUMSAL       SUM(DEPTSUMSAL)
          COSTOFLIVING
                   
DEPT      DNAME
          DEPTNO
          DEPTSUMSAL      SUM(EMP.SAL)
                   
JOB       JOB
          HEADCOUNT       COUNT(EMP.EMPNO)
                   
EMP       ENAME
          EMPNO
          SAL
          COMM

これらのグループや列で、給与に生計費手当(COSTOFLIVING)を適用する複数の式を作成します。作業が重複しないように、次のようなPL/SQLファンクションを作成して式から参照することができます。

function CompSal(salary number) return number is
begin
  return (salary*CostofLiving);
end;

次の2つは、このPL/SQLファンクションを式で参照する例です。

CompSal(:RGNSUMSAL)

or

CompSal(:SAL) + COMM

関連項目

第4.13.3.1項「ローカル・プログラム・ユニットの作成」

2.6.5 ストアド・プログラム・ユニットについて

ストアド・プログラム・ユニット(ストアド・サブプログラムやストアド・プロシージャとも呼ばれます)は、個々にコンパイルし、いつでも実行できるようにOracleデータベースに永続的に格納しておくことができます。ストアド・プログラム・ユニットをコンパイルしてデータ・ディクショナリに格納すると、スキーマ・オブジェクトとなり、そのデータベースに接続されたどのアプリケーションからでも参照できます。

ストアド・プログラム・ユニットを使用すると、生産性、パフォーマンス、アプリケーションの整合性およびセキュリティが向上し、メモリーも節約できます。たとえば、ストアド・プロシージャやストアド・ファンクションのライブラリを使用してアプリケーションを設計すると、冗長なコーディングがなくなり、生産性を向上できます。

ストアド・プログラム・ユニットは、解析およびコンパイルされた形式で格納されます。そのため、ストアド・プログラム・ユニットがコールされると、ロード後すぐにPL/SQLエンジンに渡されます。また、ストアド・プログラム・ユニットには共有メモリーが使用されます。そのため、プログラム・ユニットのコピーを1つのみメモリーにロードしておけば、複数のユーザーがそのプログラムを実行できます。

ストアド・プログラム・ユニットはOracleデータベースで実行されるので、レポートのローカルのPL/SQLよりも速くデータベース処理を実行できます。そのため、データベース処理を実行するPL/SQLには、通常ストアド・プログラム・ユニットを使用します。データベース処理を実行しないPL/SQLの場合は、ローカル・プログラム・ユニットを使用します。ただし、ネットワークの負荷が高く、レスポンス時間が非常に遅い場合には、ストアド・プログラム・ユニットを使用しても、データベース処理が速くならないことがあります。同様に、サーバーがローカル・マシンよりも非常に速い場合、ローカル・プログラム・ユニットを使用しても、データベース以外の処理が速くならないことがあります。

関連項目

第4.13.3.2項「ストアド・プログラム・ユニットの作成」

2.6.6 外部PL/SQLライブラリについて

外部PL/SQLライブラリは、レポート定義に依存しないPL/SQLプロシージャ、ファンクションおよびパッケージの集まりです。外部ライブラリをレポートに連結すると、その内容を何度でも参照できます。たとえば、連結ライブラリのプロシージャは、Before Reportトリガーとフォーマット・トリガーのどちらからでも参照できます。このため、アプリケーションごとに同じPL/SQLを再入力する必要がありません。

レポートまたは別の外部ライブラリに関連付けられた外部PL/SQLライブラリは、連結ライブラリと呼ばれます。

関連項目

第4.13.5.1項「外部PL/SQLライブラリの作成」

2.6.7 連結ライブラリについて

連結ライブラリは、レポートまたは別の外部ライブラリに関連付けられた外部PL/SQLライブラリです。外部ライブラリを連結すると、レポート内からそのパッケージ、ファンクションおよびプロシージャを参照できます。たとえば、MYLIBという外部ライブラリをレポートに連結し、そのライブラリにADDXYというファンクションが含まれる場合、レポート内のどのPL/SQLからでもADDXYを参照できます。

外部PL/SQLライブラリは、レポート定義に依存しません。

使用に関する注意

ローカルPL/SQLは、外部PL/SQLライブラリのプロシージャまたはファンクションを参照するよりも速く実行されます。そのため、多数のアプリケーション間でコードを共有する方が、パフォーマンスのオーバーヘッドよりも重要である場合にのみ、外部PL/SQLライブラリを使用してください。

制限

  • Oracle Reports Builderでは、連結ライブラリリストで指定したライブラリを検索できない場合、ダイアログ・ボックスを受け入れるとき、レポートを保存するとき、またはレポートを開くときに警告が表示されます。レポートを実行するか、レポートのPL/SQLをコンパイルしようとすると、エラーが表示されます。

  • 「連結ライブラリ」リストは保存されます。次回レポートまたはライブラリを開くと、このリストにはレポートを最後に保存したときと同じ内容が含まれています。

  • 外部ライブラリが別のライブラリを参照する場合、最初のライブラリに2つ目のライブラリがすでに連結されていても、レポートに両方のライブラリを連結する必要があります。

関連項目

第4.13.5.5項「PL/SQLライブラリの連結」

2.6.8 式について

式は、式列またはプレースホルダ列に移入するPL/SQLファンクションです。式のPL/SQLには、オブジェクト・ナビゲータ、PL/SQLエディタまたはプロパティ・インスペクタ(「PL/SQL式」プロパティ)からアクセスできます。

「データ型」プロパティがNUMBERに設定されている列は、データ型NUMBERの値を返す式のみを含めることができます。「データ型」プロパティがDATEに設定されている列は、データ型DATEの値を返す式のみを含めることができます。「データ型」プロパティがCHARACTERに設定されている列は、データ型CHARACTERVARCHARまたはVARCHAR2の値を返す式のみを含めることができます。

制限

  • 列がプレースホルダ列またはパラメータ列である場合は、式の列に値を読み込んだり、割り当てたりできますが、データベース列の値(データベースから取り出した値)は変更できません。たとえば、列COMPの値を条件に使用し(IF :COMP = 10など)、その値を直接代入文に設定することはできます(たとえば、:COMP:= 15など)。

  • 式は、グループ階層の中で同等以上のグループにある列のみを参照できます。たとえば、レポートレベルの列の式は、別のレポートレベルの列のみを参照できます。

  • 式は、その式で参照される列が最初に処理されるように計算されます。Oracle Reports Builderでは依存性リストが作成され、計算が正しい順序で実行されることが保証されます。ただし、列が別の列を参照し、参照された列が直接または間接的に最初の列を参照するような循環依存は許可されません。

  • SRW.DO_SQLを使用する場合は、同じレポートで更新または挿入されたデータベースの値を読み込まないようにしてください。Oracle Reports Builderが出力の書式設定のためにデータベースからレコードをフェッチする正確な時間は確定されません。Oracle Reports Builder内部では、パフォーマンスを最適化するために、データの先読みが行われています。そのため、特定のレコードに更新が実行される前に、同じレコードがすでにアクセスされている可能性があります。Oracle Reports Builderでは、内部依存性リストが作成され、ユーザー・イグジットの起動、サマリーの計算などのイベントが正しい順序で実行されることが保証されています。ただし、Oracle Reports Builderでは、これらのイベントと、内部データへのアクセスやデータの書式設定との同期については保証されていません。

例1: 値の追加

次の例では、給与にコミッションを足した値を列に移入します。

function salcomm return NUMBER is
begin
  return(:sal + :comm);
end;

例2: 条件の使用

次のコードでは、コミッションの値がNULL以外の場合に、給与にコミッションを足します。

function calcomm return NUMBER is
temp number;
begin
  if :comm IS NOT NULL then
    temp := :sal + :comm;
  else
    temp := :sal;
  end if;
  return (temp);
end;

関連項目

第2.3.2項「式列について」

第4.13.4.3項「式列の作成または編集」

第4.13.4.4項「プレースホルダ列の作成」

2.6.9 グループ・フィルタについて

グループ・フィルタは、グループに含めるレコードを決定します。パッケージされたフィルタの「最初」と「最後」を使用して、グループの最初のn個または最後のn個のレコードを表示できます。また、PL/SQLを使用して独自のフィルタを作成することもできます。グループ・フィルタには、オブジェクト・ナビゲータ、プロパティ・インスペクタ(「PL/SQLフィルタ」プロパティ)、またはPL/SQLエディタからアクセスできます。

このファンクションは、ブール値(TRUEまたはFALSE)を返す必要があります。ファンクションがTRUEを返すか、FALSEを返すかに応じて、現行レコードがレポートに含まれるか、レポートから除外されます。

グループ・フィルタと「フェッチする行の最大数」プロパティの相違点

「フェッチする行の最大数」プロパティでは、問合せによってフェッチする実際のレコード数が制限されます。グループ・フィルタでは、問合せによってすべてのレコードがフェッチされた後に、どのレコードを含めるか、または除外するかが判断されます。「フェッチする行の最大数」では、実際に取り出されるデータの量が制限されるため、通常、グループ・フィルタよりも実行速度が速くなります。「フィルタ・タイプ」プロパティを「最後」または条件付に設定する場合、Reports Builderでは、フィルタを適用する前に、グループ内のすべてのレコードを取り出す必要があります。問合せに対して「フェッチする行の最大数」を使用する場合も、このことを念頭に置いてください。その問合せに依存する他のグループのサマリーに影響を及ぼす可能性があります。たとえば、「フェッチする行の最大数」プロパティを8に設定すると、その問合せに基づいたサマリーには、取り出された8つのレコードのみ使用されます。

制限

  • 「フィルタ・タイプ」プロパティが「最初」または「最後」に設定されている場合、グループ・フィルタをグループに追加できません。

    グループ・フィルタはクロス積グループに追加できません。

  • グループ・フィルタに入力するファンクションは、次の列にのみ依存できます。

    • グループの問合せまたはデータ・モデル階層でそれより上位にある問合せが所有するデータベース列

    • 関連性のない問合せに依存する計算済列(式またはサマリー)(つまり、グループ、グループの親またはグループの子の列に依存しない計算済列)

  • グループ・フィルタでは、Oracle Reports Builder列の値と正しい頻度のパラメータを読み込むことができますが、それらの値は直接設定できません。たとえば、パラメータCOUNT1の値を条件に使用できますが(IF :COUNT1 = 10など)、その値を直接代入文には設定できません(:COUNT1:= 10など)。また、PL/SQLグローバル変数を使用して列またはパラメータの値を間接的に設定する機能はサポートされていません。このような設定を行うと、予期しない結果になることがあります。また、ページ依存列(つまり、「ページ」の「リセット位置」)またはグループ・フィルタのページ依存列に依存する列は参照できません。

function filter_comm return boolean is
begin
  if :comm IS NOT NULL then
    if :comm < 100 then
      return (FALSE);
    else
      return (TRUE);
    end if;
  else
    return (FALSE); -- for rows with NULL commissions
  end if;
end;

関連項目

第4.13.4.2項「グループ・フィルタの作成または編集」

2.6.10 REFカーソル問合せについて

REFカーソル問合せは、PL/SQLを使用してデータをフェッチします。各REFカーソル問合せは、カーソル変数からカーソル値を返すPL/SQLファンクションに関連付けられています。このファンクションでは、REFカーソルがオープンされ、REFカーソル型と一致するSELECTリストが含まれたSELECT文と関連付けられている必要があります。


注意:

Oracle Reports 11gリリース1(11.1.1)でREFカーソル問合せを使用するには、リリース10.1.0.5(10.1の場合)または10.2.0.2(10.2の場合)以上のデータベースが必要です。

11gリリース1(11.1.1)データベースまたはOracle Forms Servicesクライアントと10.1または10.2データベースとの相互運用性を保つためには、10.1.0.5(10.1の場合)または10.2.0.2(10.2の場合)のいずれかのレベルのパッチ・セットが最低限必要です。

10.1または10.2の環境で適切なレベルのパッチが適用されていないと、次のような状況で10.1または10.2のPL/SQLのユニットまたはビューを参照しようとしたときに、PLS-801[55916]エラーにより失敗します。

  • 11gリリース1(11.1.1)データベース上で、PL/SQLユニット、無名ブロック、トリガー、コール文またはSQL文が、10.1または10.2データベース上のPL/SQLユニットを、データベース・リンクを介してコールする。

  • 11gリリース1(11.1.1)データベース上で、PL/SQLユニット、無名ブロック、トリガーまたはコール文が、10.1または10.2データベース上のビューをデータベース・リンクを介して参照するか、ビューがPL/SQLファンクションまたはオブジェクト・タイプを直接または間接的に参照する。

  • Oracle Forms Services 11gリリース1(11.1.1)クライアントが、10.1または10.2データベース内のPL/SQLユニットを、RPCを使用してコールする。


Oracle Reportsでは、静的REFカーソルと動的REFカーソルの両方がサポートされています。次に例を示します。

静的REFカーソル:

open l_rc for SELECT * FROM emp WHERE ename = 'KING';

動的REFカーソル:

l_query := SELECT empno, ename, sal, hiredate FROM emp WHERE 1-1';
open l_rc for l_query;

注意:

動的REFカーソルの場合は、SELECT文を明示的に設定する必要があります。

詳細な例は、第41章「REFカーソルを使用したペーパー・レポートの作成」を参照してください。

使用に関する注意

  • Oracle Reportsでは、強く型付けされたREFカーソルのみがサポートされています。次に例を示します。

    type c1 is REF CURSOR RETURN emp%ROWTYPE;
    
  • データ・リンク内の子にREFカーソル問合せを作成する場合、リンクはグループ間リンクのみが有効です。列間リンクは使用できません。

  • REFカーソルの実装にストアド・プログラム・ユニットを使用する場合は、Oracleデータベースにそのプログラム・ユニットを同時に格納できるという利点があります。

  • 次のことを行うときに問合せの基準としてREFカーソルを使用します。

    • より簡単なSQLの管理

    • レポート内での文字パラメータの使用の回避

    • Form Builderなどの他のアプリケーションとのデータ・ソースの共有

    • 制御とセキュリティの向上

    • サブプログラム内のロジックのカプセル化

さらに、REFカーソルの実装にストアド・プログラム・ユニットを使用する場合は、Oracleデータベースにそのプログラム・ユニットを同時に格納できるという利点があります。

REFカーソルとストアド・サブプログラムの詳細は、『PL/SQLユーザーズ・ガイドおよびリファレンス』を参照してください。

例1: REFカーソルが含まれるパッケージの例

/* This package spec defines a REF CURSOR
** type that could be referenced from a
** REF CURSOR query function.
** If creating this spec as a stored
** procedure in a tool such as SQL*Plus,
** you would need to use the CREATE
** PACKAGE command.
*/
 
PACKAGE cv IS
type comp_rec is RECORD 
  (deptno number,
   ename varchar(10),
   compensation number);
type comp_cv is REF CURSOR return comp_rec;
END;

例2: REFカーソルとファンクションが含まれるパッケージ

/* This package spec and body define a ref
** cursor type as well as a function that
** uses the REF CURSOR to return data.
** The function could be referenced from
** the REF CURSOR query, which would
** greatly simplify the PL/SQL in the
** query itself. If creating this spec
** and body as a stored procedure in a
** tool such as SQL*Plus, you would need
** to use the CREATE PACKAGE and CREATE
** PACKAGE BODY commands.
*/
 
PACKAGE cv IS
type comp_rec is RECORD
  (deptno number,
   ename varchar(10),
   compensation number);
type comp_cv is REF CURSOR return comp_rec;
function emprefc(deptno1 number) return comp_cv;
END;
 
PACKAGE BODY cv IS
function emprefc(deptno1 number) return comp_cv is
  temp_cv cv.comp_cv;
begin
  if deptno1 > 20 then
    open temp_cv for select deptno, ename,
    1.25*(sal+nvl(comm,0)) compensation
    from emp where deptno = deptno1;
  else
    open temp_cv for select deptno, ename,
    1.15*(sal+nvl(comm,0)) compensation
    from emp where deptno = deptno1; 
  end if;
  return temp_cv;
end;
END;

例3: REFカーソル問合せ

/* This REF CURSOR query function would be coded
** in the query itself. It uses the cv.comp_cv
** REF CURSOR from the cv package to return
** data for the query.
*/
function DS_3RefCurDS return cv.comp_cv is
  temp_cv cv.comp_cv;
begin
  if :deptno > 20 then
    open temp_cv for select deptno, ename,
    1.25*(sal+nvl(comm,0)) compensation
    from emp where deptno = :deptno;
  else
   open temp_cv for select deptno, ename,
   1.15*(sal+nvl(comm,0)) compensation
   from emp where deptno = :deptno;
  end if;
  return temp_cv;
end;

例4: REFカーソル問合せコール側ファンクション

/* This REF CURSOR query function would be coded
** in the query itself. It uses the cv.comp_cv
** REF CURSOR and the cv.emprefc function from
** the cv package to return data for the query.
** Because it uses the function from the cv
** package, the logic for the query resides
** mainly within the package. Query
** administration/maintenance can be
** done at the package level (for example,
** modifying SELECT clauses could be done
** by updating the package). You could also
** easily move the package to the database.
** Note this example assumes you have defined
** a user parameter named deptno.
*/

function DS_3RefCurDS return cv.comp_cv is
  temp_cv cv.comp_cv;
begin
  temp_cv := cv.emprefc(:deptno);
  return temp_cv;
end;

関連項目

第4.8.1.7項「問合せの作成: REFカーソル問合せツール」

2.6.11 DMLとDDLについて

PL/SQLでデータ操作言語(DML)またはデータ定義言語(DDL)を使用する場合は、SRW.DO_SQLビルトイン・プロシージャを使用できます。SRW.DO_SQLは、DMLおよびDDLでのみ使用し、データのフェッチには使用しないでください。DMLおよびDDLの詳細は、『Oracle Database SQLリファレンス』を参照してください。

Oracle Reportsの処理モデルにより、DDLはBefore Parameter FormトリガーおよびAfter Parameter Formトリガーのみで使用することをお薦めします。DMLは、PL/SQLが受け入れられる場所ならどこにでも入力できます。

このレポートの処理で報告されるDMLまたはDDLは、After Parameter Formトリガーで(またはその前で)実行する必要があります。Before Reportトリガーでは整合性は保証できません。これは、Oracle Reportsが、レポートの定義に基づいて、そのトリガーの前にデータ・カーソルでの作業を開始する必要があるためです。Before Reportトリガーの前にOracle Reports Builderで必ず行われることは、関連する表を記述し、カーソルを開くことです。これ以降に表で行った変更は、レポートに表示されません。

関連項目

第2.6.13.1項「レポート・トリガーについて」

2.6.12 ビルトイン・パッケージについて

ビルトイン・パッケージは、論理的に関連するPL/SQL型、オブジェクト、ファンクションやプロシージャの集まりです。これは通常、パッケージ仕様部(データ宣言を含む)とパッケージ本体という2つの部分で構成されます。パッケージを使用すると、グローバル変数を作成できるので非常に便利です。

Oracleには複数のパッケージ・プロシージャが用意されており、PL/SQLベースのアプリケーションを構築またはデバッグするときに使用できます。PL/SQLコードでは、次に説明するように、Oracle Reports Builderビルトイン・パッケージ(SRW)と各種のツール・ビルトイン・パッケージのプロシージャ、ファンクションおよび例外を使用できます。

2.6.12.1 Oracle Reports Builderビルトイン・パッケージ(SRW)について

Oracle Reports Builderには、ビルトイン・パッケージ(SRW)が付属しています。ビルトイン・パッケージは、様々なファンクション、プロシージャおよび例外が含まれたPL/SQL構文の集まりで、ライブラリまたはレポートで参照できます。

SRWパッケージに含まれるPL/SQLでは、フィールドの書式設定の変更、他のレポートからのレポートの実行、レポート・エラー時に表示するカスタマイズ・メッセージの作成、およびSQL文の実行などのアクションを実行できます。

SRWパッケージの内容は、連結されていなくても、ライブラリまたはレポートから参照できます。ただし、SQL*Plusなどの別の製品からこの内容を参照することはできません。

パッケージに含まれる構文は通常、パッケージ・ファンクション、パッケージ・プロシージャおよびパッケージ例外のように「パッケージ」を付けて呼びます。

関連項目

Oracle Reportsオンライン・ヘルプの「リファレンス」の項のトピック「SRWビルトイン・パッケージ」

2.6.12.2 ツール・ビルトイン・パッケージについて

各種のPL/SQL構文を含むいくつかのクライアント側ビルトイン・パッケージが用意されており、アプリケーションの構築やアプリケーション・コードのデバッグ時に参照できます。これらのビルトイン・パッケージは、パッケージSTANDARDの拡張機能としてインストールされません。このため、いずれかのパッケージの構文を参照するたびに、その名前の前にパッケージ名を付ける必要があります(TEXT_IO.PUT_LINEなど)。

次のようなツール・ビルトイン・パッケージがあります。

  • DDE

    Oracle Reports Builderコンポーネント内で動的データ交換(DDE)をサポートします。

  • DEBUG

    PL/SQLプログラム・ユニットをデバッグする際のプロシージャ、ファンクションおよび例外が含まれます。これらのビルトイン・サブプログラムを使用すると、デバッグ・トリガーを作成し、トリガーでブレークポイントを設定できます。

  • EXEC_SQL

    Oracle Reports Builderアプリケーションに作成したPL/SQLコード内で、動的SQLを実行するためのプロシージャとファンクションが含まれます。

  • LIST

    文字列(VARCHAR2)のリストを作成および保守するために使用できるプロシージャ、ファンクションおよび例外が含まれます。これを使用すると、PL/SQLバージョン1で配列を作成できるようになります。

  • ORA_FFI

    ダイナミック・ライブラリのC関数をコールする外部関数インタフェースが含まれます。

  • ORA_JAVA

    PL/SQLからJavaクラスをコールするインタフェースが含まれます。

  • ORA_NLS

    現行の言語環境に関する詳細な情報を取り出せるようにします。この情報を使用して、言語の属性を調べ、ローカルの日付と数値形式を使用してアプリケーションをカスタマイズできます。また、キャラクタ・セットの照合に関する情報と、一般的なキャラクタ・セットも取得できます。現行の言語名とキャラクタ・セットを検索する機能も用意されており、特殊なケースをテストし、利用するアプリケーションを作成できます。

  • ORA_PROF

    PL/SQLプログラム・ユニットのチューニング(たとえば、特定のコード部分を実行するのにどれぐらいの時間がかかるか調べる)に使用できるプロシージャ、ファンクションおよび例外が含まれます。

  • TEXT_IO

    ファイルからの情報の読込み、ファイルへの情報の書込みを可能にする構文が含まれます。Text_IOで使用可能なプロシージャやファンクションは、次のカテゴリに分類されます。

    • ファイル操作。FILE_TYPEレコード、FOPENファンクションやIS_OPENファンクション、およびFCLOSEプロシージャを使用すると、FILE_TYPE変数を定義し、ファイルを開き、開いたファイルをチェックし、それらのファイルを閉じることができます。

    • 出力(書込み)操作。PUT、PUTF、PUT_LINEおよびNEW_LINEの各プロシージャを使用すると、開いているファイルに情報を書き込んだり、PL/SQLインタプリタに情報を出力したりできます。

    • 入力(読取り)操作。GET_LINEプロシージャを使用すると、開いているファイルから行を読み込むことができます。

  • TOOL_ENV

    サブプログラムで使用する値を取り出して、Oracle環境変数と対話できるようにします。

  • TOOL_ERR

    DEBUGなどの別のビルトイン・パッケージで作成したエラー・スタックにアクセスし、操作できるようにします。

    一部のビルトイン・パッケージ(たとえば、DEBUGパッケージ)では、エラーを示すために例外を使用するだけでなく、追加のエラー情報も提供します。この情報は、エラー・スタックの形式で保持されます。

    エラー・スタックには、詳細なエラー・コードと関連するエラー・メッセージが含まれます。スタック上のエラーには、ゼロ(最古)からn-1(最新)の番号が付けられます。nはスタック上に現在あるエラー数です。TOOL_ERRパッケージのサービスを使用すると、エラー・スタックにアクセスし、操作できます。

  • TOOL_RES

    PL/SQLコードを移植しやすくするため、リソース・ファイルのすべてのテキスト・データを分離して、リソース・ファイルから文字列リソースを抽出します。

次のパッケージは、Oracle Reportsの内部でのみ使用されます。これらのパッケージには、外部で使用できるサブプログラムはありません。

  • ORA_DE

    ReportsによりプライベートPL/SQLサービスで使用される構文が含まれます。

  • STPROC

    データベースに格納されたサブプログラムをコールします。このパッケージへのコールは自動的に生成されます。注意: Oracle Reports 11gリリース1(11.1.1)では、STPROCが廃止されています。

  • JNI

    PL/SQLからJavaをコールしやすくします。

関連項目

Oracle Reportsオンライン・ヘルプの「リファレンス」→「PL/SQLリファレンス」→「ビルトイン・パッケージ」の項の各ツール・ビルトイン・パッケージに関するトピック

2.6.13 トリガーについて

トリガーではイベントをチェックします。イベントが発生すると、トリガーに関連付けられたPL/SQLコードが実行されます。

レポート・トリガーは、レポートに含まれるデータではなく、レポートを開いたり閉じたりするレポート・イベントに対応してアクティブ化されます。アクティブ化される順序はどのレポートにもあらかじめ定義されています。

フォーマット・トリガーは、オブジェクトをフォーマットする前に実行されます。フォーマット・トリガーは、オブジェクトのフォーマット属性を動的に変更するときに使用できます。

検証トリガーは、コマンドラインでパラメータ値が指定された場合、およびランタイム・パラメータ・フォームを受け入れた場合に実行されるPL/SQLファンクションです。

データベース・トリガーは、データベースに格納され、INSERTUPDATEまたはDELETEなどのトリガー文が、関連付けられた表に発行されたときに、暗黙的に実行されるプロシージャです。

2.6.13.1 レポート・トリガーについて

レポート・トリガーは、レポートの実行およびフォーマット時に、所定回数だけPL/SQLファンクションを実行します。これらのトリガーに、PL/SQLの条件付き処理機能を使用すると、レポート・フォーマットのカスタマイズ、初期化タスクの実行、およびデータベースへのアクセスなどを行うことができます。レポート・トリガーを作成または変更するには、オブジェクト・ナビゲータの「レポート・トリガー」ノードを使用します。レポート・トリガーは、明示的にTRUEまたはFALSEを返す必要があります。

Oracle Reportsには、次のような5つのグローバル・レポート・トリガーがあります。新しいグローバル・レポート・トリガーは作成できません。トリガー名は、トリガーをどの時点で起動するかを示します。

  • Before Reportトリガー: 問合せが解析された後、レポートが実行される前に起動します。

  • After Reportトリガー: ペーパー・デザイン・ビューを終了した後、またはレポート出力が指定の出力先(ファイル、プリンタ、電子メールIDなど)に送信された後に起動します。このトリガーを使用すると、表の削除など、完了した初期処理をクリーンアップできます。ただし、このトリガーは、レポートが正常に完了したかどうかにかかわらず、常に起動されることに注意してください。

  • Between Pagesトリガー: 最初のページを除き、レポートの各ページがフォーマットされる前に起動します。このトリガーは、カスタマイズされたページのフォーマットに使用できます。ペーパー・デザイン・ビューでは、このトリガーは任意のページに最初に移動したときにのみ起動します。後でそのページに戻っても、トリガーは再度起動されません。

  • Before Parameter Formトリガー: ランタイム・パラメータ・フォームが表示される前に起動します。このトリガーから、パラメータ、PL/SQLグローバル変数およびレポート・レベルの列の値にアクセスし、変更できます。ランタイム・パラメータ・フォームが表示されていない場合でも、このトリガーは起動します。そのため、このトリガーは、コマンドライン・パラメータの検証に使用できます。

  • After Parameter Formトリガー: ランタイム・パラメータ・フォームが表示された後に起動します。このトリガーから、パラメータにアクセスして値をチェックできます。このトリガーを使用すると、パラメータの値を変更したり、エラーが発生した場合にランタイム・パラメータ・フォームに戻ることもできます。データ・モデルの列は、このトリガーからはアクセスできません。ランタイム・パラメータ・フォームが表示されていない場合でも、After Parameter Formトリガーは起動します。そのため、このトリガーは、コマンドライン・パラメータまたはその他のデータの検証に使用できます。

レポート・トリガー実行の順序

レポート実行時のイベントの順序は次のとおりです。

  1. Before Parameter Formトリガーが起動します。


    注意:

    パラメータ・フォームがWeb上で使用されている場合、Before Parameter Formトリガーは2回起動します。1回はパラメータ・フォームが表示されたとき、もう1回はパラメータが送信されたときです。これは、Oracle Reportsがステートレスに実行されるためです。戻り先のセッションがないため、Before Parameter Formトリガーを2回起動することによって、パラメータ・フォームで選択されてコマンドラインに渡されたパラメータが有効であることを確認する必要があります。

  2. ランタイム・パラメータ・フォームが表示されます(非表示になっていない場合)。

  3. After Parameter Formトリガーが起動します(ユーザーがランタイム・パラメータ・フォームからキャンセルしない場合)。

  4. レポートがコンパイルされます。

  5. 問合せが解析されます。

  6. Before Reportトリガーが起動します。

  7. SET TRANSACTION READONLYが実行されます(READONLYコマンドライン・キーワードまたは設定で指定されている場合)。

  8. レポートが実行され、最初のページを除く各ページでBetween Pagesトリガーが起動します(データは、レポートのフォーマット中にいつでもフェッチできます)。この間に、SRW.DO_SQLをDDLで使用しているため、またはONFAILURE=COMMITでレポートが失敗した場合に、COMMITが発生することがあります。

  9. COMMITが実行され(READONLYが指定されている場合)、トランザクションが終了します。

  10. After Reportトリガーが起動します。

  11. ONSUCCESSコマンドライン・キーワードまたは設定での指定に基づいて、COMMIT、ROLLBACK、NOACTIONのいずれかが実行されます。

使用に関する注意

  • 手順4〜9では、レポートのベースとなっている表を修正するDDL文は避けてください。手順3では、表のスナップショットがとられます。このスナップショットは、レポートを実行中は有効なままにする必要があります。手順7〜9では、レポートのベースとなっている表の内容を修正するDML文は避けてください。問合せがどんな順序でも実行可能になり、DML文が信頼できなくなる場合があります(レポートで使用されていない表で実行する場合は除きます)。

  • コマンドラインでREADONLYを指定する場合は、DDLをすべて使用しないでください。DDL文(たとえば、SRW.DO_SQLで)を実行すると、COMMITが自動的に発行されます。READONLYを使用している場合、SET TRANSACTION READONLYによって開始したトランザクションが未完了のまま終了します。

  • 通常は、レポートによって取得されるデータに影響する処理は、すべてBefore Parameter FormトリガーまたはAfter Parameter Formトリガーで実行する必要があります(これらの2つは、解析やフェッチが行われる前に起動するレポート・トリガーです)。レポートによって取得されるデータに影響しない処理は、他のトリガーで実行できます。

  • After Parameter Formトリガーで(または前に)DMLやDDLを使用した場合でも、整合性が確保されます。ただし、Before Reportトリガーでは整合性は確保されません。これは、Oracle Reportsが、レポートの定義に基づいて、そのトリガーの前にデータ・カーソルでの作業を開始する必要があるためです。Before Reportトリガーの前に、Oracle Reportsは関連する表を記述し、カーソルを開きます。これ以降に表で行った変更は、レポートに表示されません。

制限

  • レポート出力をペーパー・デザイン・ビューまたはプレビューアに送信する場合は、レポート出力が表示される前に一部またはすべてのレポート・トリガーが起動する場合があることに注意してください。たとえば、SRW.MESSAGEを使用して、条件が満たされたときにBetween Pagesトリガーでメッセージを発行するとします。レポートに前方参照がある場合(ページの合計数を最後のページの前に表示するなど)、Oracle Reportsでは事前にフォーマットして前方参照を計算する必要があります。したがって、まだ確認していないページでも、すでにフォーマットされトリガーが起動されている場合があります。

  • レポート・トリガーでは、レポート・レベルの列およびパラメータの値を使用できます。たとえば、COUNT1というパラメータの値が、ある条件(IF :COUNT1 = 10など)で必要な場合があります。ただし、ページ依存列(「リセット位置」プロパティが「ページ」に設定されている列)またはページ依存列に依存する列は参照できません。

  • Before Parameter FormトリガーとAfter Parameter Formトリガー、およびBefore ReportトリガーとAfter Reportトリガーでは、パラメータの値を設定できます(たとえば、代入文:COUNT1 = 15で値を指定できます)。Before ReportトリガーとAfter Reportトリガーでは、レポート・レベルのプレースホルダ列の値も設定できます。

  • Between Pagesトリガーでは、データ・モデル・オブジェクトの値は設定できません。また、PL/SQLグローバル変数を使用して列またはパラメータの値を間接的に設定する機能はお薦めしません。このような設定を行うと、予期しない結果になることがあります。

  • 字句参照を使用して、After Parameter Formトリガーの起動後に追加されるバインド変数を作成することはできません。たとえば、次のような問合せがあるとします(WHERE句が字句参照によって置換されることに注意してください)。

    SELECT ENAME, SAL FROM EMP &WHERE_CLAUSE

    WHERE_CLAUSEパラメータの値にバインド変数への参照が含まれる場合は、After Parameter Formトリガーでその値を指定するか、事前に指定する必要があります。Before Reportトリガーでパラメータに次の値を設定すると、エラーが発生します。After Parameter Formトリガーで同じ値を設定すると、レポートが実行されます。

    WHERE SAL = :new_bind

関連項目

第4.13.3.5項「レポート・トリガーの作成」

第4.13.3.6項「レポート・トリガーの削除」

2.6.13.2 フォーマット・トリガーについて

フォーマット・トリガーは、オブジェクトがフォーマットされる前に実行されるPL/SQLファンクションです。トリガーは、オブジェクトのフォーマット属性を動的に変更するときに使用できます。たとえば、フォーマット・トリガーを使用して、値がゼロ未満の場合に太字で表示できます。また、フォーマット・トリガーを使用して、値が1,000,000より大きい場合にそのフィールドに科学表記法を使用できます。

フォーマット・トリガーは、Oracle Reports Builderが特定オブジェクトのフォーマットを試行するたびに、そのオブジェクトで起動できます。Oracle Reports Builderが、ページの一番下にあるオブジェクトのフォーマットを開始するとします。オブジェクトがそのページ上に収まらない場合、Oracle Reports Builderはフォーマットを中止し、次のページで再フォーマットを行います。この場合、フォーマット・トリガーは2回起動します。したがって、このトリガーでは、ロギングなどの永続的な処理を行うことはお薦めしません。

Oracle Reports Builder SRWビルトイン・パッケージには、オブジェクトのフォーマット属性を簡単に変更できるPL/SQLプロシージャが含まれています。これには、次のような処理を行うプロシージャがあります。

  • オブジェクトの境界線パターンとカラーを変更する

  • オブジェクトの内部パターンとカラーを変更する

  • フィールドまたはボイラープレート・テキストのフォント・サイズ、スタイル、太さ、間隔および文字間調整を変更する

  • フィールドの書式マスクを変更する

  • フィールドの値にアクセスする

Oracle Reportsオンライン・ヘルプの「リファレンス」の項のトピック「フォーマット・トリガー」を参照してください。

関連項目

第4.13.4.1項「フォーマット・トリガーの作成または編集」

2.6.13.3 検証トリガーについて

検証トリガーは、コマンドラインでパラメータ値が指定された場合、およびランタイム・パラメータ・フォームを受け入れた場合に実行されるPL/SQLファンクションです。


注意:

JSPベースのWebレポートの場合、Oracle Reports Builderでレポートを実行するとランタイム・パラメータ・フォームが表示されますが、Oracle Reports Servicesのランタイム環境では表示されません。ランタイム・パラメータ・フォームでパラメータを指定しないと、検証トリガーはFALSEを返し、エラー・メッセージ「REP-0546: 入力されたパラメータは無効です。」を出力します。このため、第1.9.4項「Webレポートのパラメータ・フォームについて」に記載されたように、別の方法でパラメータを指定する必要があります。

検証トリガーは、パラメータの「初期値」プロパティを検証するときにも使用します。ファンクションがTRUEを返すか、FALSEを返すかに応じて、ランタイム・パラメータ・フォームに戻ります。

Oracle Reportsオンライン・ヘルプの「リファレンス」の項の検証トリガーに関するトピック参照してください。

関連項目

第4.11.4項「実行時におけるパラメータ値の検証」

2.6.13.4 データベース・トリガーについて

データベース・トリガーは、データベースに格納され、INSERT、UPDATEまたはDELETEなどのトリガー文が関連付けられた表に発行されたときに暗黙的に実行されるプロシージャです。トリガーは、表でのみ定義でき、ビューでは定義できません。ただし、ビューの実表のトリガーは、INSERT、UPDATEまたはDELETE文がビューに対して発行された場合に起動します。

トリガーは、ユニットとして実行されるSQL文およびPL/SQL文を含めることができ、別のストアド・プロシージャをコールできます。トリガーは、必要な場合にのみ使用してください。トリガーを多用すると、カスケード・トリガーや再帰的トリガーが発生することがあります。たとえば、トリガーが起動されたときに、トリガー本体のSQL文が別のトリガーを起動することがあります。

データベース・トリガーを使用すると、複合ビジネス・ルールを規定し、すべてのアプリケーションを同じように動作させることができます。トリガーを作成する場合は、次のガイドラインに従います。

  • トリガーは、特定の操作が実行されたときに、関連するアクションを実行させる場合に使用します。

  • データベース・トリガーは、トリガーを実行する文で起動される集中化されたグローバル操作にのみ使用します。その際にどのユーザーまたはデータベース・アプリケーションがその文を発行したかは問いません。

  • Oracleデータベースにすでに組み込まれている機能と重複するトリガーは定義しないでください。たとえば、宣言整合性制約を使用して簡単に施行できるような、データ整合性規則を規定するトリガーは定義しないでください。

  • トリガーのサイズを制限します(目安として60行以下)。トリガーの論理で61行以上のPL/SQLコードが必要な場合、コードの大部分をストアド・プロシージャに含め、トリガーからそのプロシージャをコールすることをお薦めします。

  • 再帰的トリガーは作成しないでください。たとえば、EMPでUPDATE文を発行するEMP表にAFTER UPDATE文トリガーを作成すると、メモリーがなくなるまでトリガーが繰り返して起動されます。

アプリケーションでのトリガーの使用方法の詳細は、『Oracleアプリケーション開発者ガイド』を参照してください。各種トリガーの詳細は、『Oracleデータベース概要』を参照してください。

関連項目

第4.13.3.7項「データベース・トリガーの作成」