識別子

命名規則と暗黙オブジェクト名の修飾

データベース・オブジェクト名の形成の規則は、名前で指定されるオブジェクトのタイプに応じて異なります。 名前は単一の SQL ID で構成するか、オブジェクトをより明確に識別する 1 つ以上の ID で修飾することができます。 各 ID はピリオドで区切ります。

構文図では、名前の種類ごとに異なる用語を使用します。 以下のリストは、それらの用語を定義しています。

alias-name

別名を指定するスキーマ修飾名。

attribute-name

構造化データ・タイプの属性を指定する ID。

array-type-name

ユーザー定義の配列タイプを指定する修飾された名前または非修飾の名前。 array-type-name の非修飾形式は SQL ID です。 SQL ステートメントにおける非修飾の配列タイプ名は、暗黙のうちに修飾されます。 暗黙の修飾子は、 スキーマ名またはモジュール名であり、これは、array-type-name が出現しているコンテキストによって決まります。 修飾形式は、schema-name の後にピリオドと SQL ID が続くか、module-name (schema-name で修飾することもできる) の後にピリオドと SQL ID が続きます。 配列タイプがモジュールで定義されており、同じモジュールの外部で使用される場合は、module-name で修飾する必要があります。

authorization-name

ユーザー、グループ、またはロールを指定する ID。 ユーザーまたはグループの場合:

• 有効な文字は、「A」から「Z」、「a」から「z」、「0」から「9」、「#」、「@」、「$」、「_」、「!」、「(」、「)」、「{」、「}」、「-」、「.」、「^」です。
• 次の文字は、コマンド行プロセッサーを使用して入力する場合、引用符で区切る必要があります:「!」、「(」、「)」、「{」、「}」、「-」、「.」、「^」
• 名前は、SYS、IBM、または、SQL という文字で始めることはできません。
• 名前は、ADMINS、GUESTS、LOCAL、PUBLIC、または USERS であってはなりません。
• 区切り許可 ID に小文字を使用することはできません。

bufferpool-name

バッファー・プールを指定する ID。

列名

表またはビューの列を指定する修飾された名前または非修飾の名前。 修飾子は、表名、ビュー名、ニックネーム、または相関名です。

component-name

セキュリティー・ラベル・コンポーネントを指定する ID。

condition-name

条件を指定する修飾された名前または非修飾の名前。 SQL ステートメントにおける非修飾の条件名は、そのコンテキストに応じて暗黙のうちに修飾されます。 条件がモジュールで定義されており、同じモジュールの外部で使用される場合は、module-name で修飾する必要があります。

constraint-name

参照制約、主キー制約、ユニーク制約、または表チェック制約を指定する ID。

correlation-name

結果表を指定する ID。

cursor-name

SQL カーソルを指定する ID。 ホストとの互換性を保つため、この名前にハイフン文字を使用することもできます。

cursor-type-name

ユーザー定義のカーソル・タイプを指定する修飾された名前または非修飾の名前。 cursor-type-name の非修飾形式は SQL ID です。 SQL ステートメントにおける非修飾の cursor-type-name は、コンテキストに応じて暗黙のうちに修飾されます。 暗黙の修飾子は、 スキーマ名またはモジュール名であり、これは、cursor-type-name が出現しているコンテキストによって決まります。 修飾形式は、schema-name の後にピリオドと SQL ID が続くか、module-name (schema-name で修飾することもできる) の後にピリオドと SQL ID が続きます。 カーソル・タイプがモジュールで定義されており、同じモジュールの外部で使用される場合は、module-name で修飾する必要があります。

cursor-variable-name

カーソル・タイプのグローバル変数、ローカル変数、または SQL パラメーターを指定する、修飾子された名前または非修飾の名前。 SQL ステートメントにおける非修飾のカーソル変数名は、コンテキストに応じて暗黙のうちに修飾されます。

data-source-name

データ・ソースを指定する ID。 この ID は、3 つの部分に分かれたリモート・オブジェクト名の最初の部分を成します。

db-partition-group-name

データベース・パーティション・グループを指定する ID。

descriptor-name

コロンの後に、SQL 記述子域 (SQLDA) を指定するホスト ID を付けたもの。 ホスト ID の説明については、 ホスト変数への参照を参照してください。 記述子名には標識変数は使用されません。

distinct-type-name

特殊タイプを指定する修飾された名前または非修飾の名前。 distinct-type-name の非修飾形式は SQL ID です。 SQL ステートメントにおける非修飾の特殊タイプ名は、暗黙のうちに修飾されます。 暗黙の修飾子は、スキーマ名またはモジュール名です。どのスキーマ名またはモジュール名が使用されるかは、distinct-type-name が出現するコンテキストで判別されます。 修飾形式は、schema-name の後にピリオドと SQL ID が続くか、module-name (schema-name で修飾することもできる) の後にピリオドと SQL ID が続きます。 特殊タイプがモジュールで定義されており、同じモジュールの外部で使用される場合は、module-name で修飾する必要があります。

event-monitor-name

イベント・モニターを指定する ID。

function-mapping-name

関数マッピングを指定する ID。

function-name

関数を指定する、修飾された名前または非修飾の名前。 function-name の非修飾形式は SQL ID です。 SQL ステートメントにおける非修飾の関数名は、暗黙のうちに修飾されます。 暗黙の修飾子は、スキーマ名です。どのスキーマ名が使用されるかは、function が出現するコンテキストで判別されます。 修飾形式は、schema-name の後にピリオドと SQL ID が続くか、module-name の後にピリオドと SQL ID が続きます。 関数がモジュールでパブリッシュされており、同じモジュールの外部で使用される場合は、module-name で修飾する必要があります。

global-variable-name

グローバル変数を指定する、修飾された名前または非修飾の名前。 global-variable-name の非修飾形式は SQL ID です。 SQL ステートメントにおける非修飾のグローバル変数名は、暗黙のうちに修飾されます。 暗黙の修飾子は、 スキーマ名またはモジュール名であり、これは、global-variable-name が出現しているコンテキストによって決まります。 修飾形式は、schema-name の後にピリオドと SQL ID が続くか、module-name (schema-name で修飾することもできる) の後にピリオドと SQL ID が続きます。 グローバル変数がモジュールで定義されており、同じモジュールの外部で使用される場合は、module-name で修飾する必要があります。

group-name

構造化タイプ用に定義した変換グループを指定する、非修飾の ID。

host-variable

ホスト変数を指定するトークンを連結したもの。 ホスト変数には、少なくとも 1 つのホスト ID が含まれています。これについては、 ホスト変数への参照で説明しています。

index-name

索引または SPECIFICATION ONLY 指定の索引を指定するスキーマによって修飾された名前。

ラベル

SQL プロシージャーのラベルを指定する ID。

method-name

メソッドを指定する ID。 メソッドのスキーマ・コンテキストは、そのメソッドのサブジェクト・タイプ (または、 サブジェクト・タイプのスーパータイプ) のスキーマによって決まります。

module-name

モジュールを指定する修飾された名前または非修飾の名前。 SQL ステートメントにおける非修飾の module-name は、暗黙のうちに修飾されます。 暗黙の修飾子は、スキーマ名です。どのスキーマ名が使用されるかは、module-name が出現するコンテキストで判別されます。 修飾形式は、schema-name の後にピリオドと SQL ID が続きます。

nickname

フェデレーテッド・サーバーが表またはビューに参照することを指定する、 スキーマによって修飾された名前。

パッケージ名

パッケージを指定する、修飾された名前または非修飾の名前。

parameter-name

プロシージャー、ユーザー定義関数、メソッド、 または索引拡張機能で参照できるパラメーターを指定する ID。

partition-name

パーティション表内のデータ・パーティションを指定する ID。

period-name

期間を指定する ID。 SYSTEM_TIME および BUSINESS_TIME のみが、期間名としてサポートされています。

procedure-name

プロシージャーを指定する修飾された名前または非修飾の名前。 procedure-name の非修飾形式は SQL ID です。 SQL ステートメントにおける非修飾のプロシージャー名は、暗黙のうちに修飾されます。 暗黙の修飾子は、スキーマ名です。どのスキーマ名が使用されるかは、procedure が出現するコンテキストで判別されます。 修飾形式は、schema-name の後にピリオドと SQL ID が続くか、module-name の後にピリオドと SQL ID が続きます。 プロシージャーがモジュールで定義されており、同じモジュールの外部で使用される場合は、 module-name で修飾する必要があります。

remote-authorization-name

データ・ソースのユーザーを指定する ID。 許可名に関する規則は、データ・ソースごとに異なります。

remote-function-name

データ・ソース・データベースに登録されている関数を指定する名前。

remote-object-name

データ・ソース表またはビューを指定するとともに、 その表またはビューが置かれているデータ・ソースを識別する 3 つの部分に分かれた名前。 この名前は、data-source-name、remote-schema-name、および remote-table-name の各部分で構成されます。

remote-schema-name

データ・ソース表またはビューが属するスキーマを指定する名前。 この名前は、3 つの部分に分かれたリモート・オブジェクト名の 2 番目の部分を成します。

remote-table-name

データ・ソースにある表またはビューを指定する名前。 この名前は、3 つの部分に分かれたリモート・オブジェクト名の 3 番目の部分を成します。

remote-type-name

データ・ソース・データベースがサポートするデータ・タイプ。 組み込まれたタイプの場合は、長形式を使用しないでください (例えば、 CHARACTER ではなく CHAR を使用してください)。

role-name

ロールを指定する ID。

row-type-name

ユーザー定義の 行タイプを指定する修飾された名前または非修飾の名前。 row-type-name の非修飾形式は SQL ID です。 SQL ステートメントにおける非修飾の row-type-name は、暗黙のうちに修飾されます。 暗黙の修飾子は、 スキーマ名またはモジュール名であり、これは、row-type-name が出現しているコンテキストによって決まります。 修飾形式は、schema-name の後にピリオドと SQL ID が続くか、module-name (schema-name で修飾することもできる) の後にピリオドと SQL ID が続きます。 行タイプがモジュールで定義されており、同じモジュールの外部で使用される場合は、module-name で修飾する必要があります。

savepoint-name

セーブポイントを指定する ID。

schema-name

SQL オブジェクトを論理的にグループ化するための ID。 オブジェクト名の修飾子として使用されるスキーマ名は、 以下のものから暗黙的に決定されます。

• CURRENT SCHEMA 特殊レジスターの値
• QUALIFIER プリコンパイル/BIND オプションの値
• CURRENT PATH 特殊レジスターを使用する解決アルゴリズムに基づいて
• 同一の SQL ステートメントにある別のオブジェクトのスキーマ名に基づいて

混乱を避けるために、スキーマとして SESSION という名前は使わないようにお勧めします。 ただし、宣言済みのグローバル一時表のスキーマは除きます (この場合は、 スキーマ名 SESSION を使用する必要があります)。

security-label-name

セキュリティー・ラベルを指定する、修飾された名前または非修飾の名前。 SQL ステートメントにおける非修飾のセキュリティー・ラベル名は、該当する security-policy-name がある場合、それによって暗黙のうちに修飾されます。 暗黙的に適用できる security-policy-name が存在しない場合、この名前は修飾されている必要があります。

security-policy-name

セキュリティー・ポリシーを指定する ID。

sequence-name

シーケンスを指定する ID。

server-name

アプリケーション・サーバーを指定する ID。 フェデレーテッド・システムでは、サーバー名によってデータ・ソースのローカル名も指定します。

specific-name

ユニーク名を指定する、修飾された名前または非修飾の名前。 SQL ステートメントにおける非修飾のユニーク名は、コンテキストに応じて暗黙のうちに修飾されます。

SQL-variable-name

SQL プロシージャー・ステートメントのローカル変数名。 SQL 変数名は、ホスト変数名が許可されている他の SQL ステートメントで使うこともできます。 この名前に対しては、SQL 変数を宣言したコンパウンド・ステートメントのラベルで修飾できます。

statement-name

作成済み SQL ステートメントを指定する ID。

storagegroup-name

ストレージ・グループを指定する ID。

supertype-name

タイプのスーパータイプを指定する修飾された名前または非修飾の名前。 SQL ステートメントにおける非修飾のスーパータイプ名は、コンテキストに応じて暗黙のうちに修飾されます。

table-name

表を指定するスキーマによって修飾された名前。

table-reference

表を指定する修飾された名前または非修飾の名前。 共通表式における非修飾の表参照は、デフォルト・スキーマによって暗黙のうちに修飾されます。

tablespace-name

表スペースを指定する ID。

trigger-name

トリガーを指定するスキーマによって修飾された名前。

type-mapping-name

データ・タイプ・マッピングを指定する ID。

type-name

型を指定する修飾された名前または非修飾の名前。 SQL ステートメントにおける非修飾のタイプ名は、コンテキストに応じて暗黙のうちに修飾されます。

typed-table-name

タイプ表を指定するスキーマによって修飾された名前。

typed-view-name

タイプ・ビューを指定するスキーマによって修飾された名前。

usage-list-name

使用量リストを指定するスキーマによって修飾された名前。

user-defined-type-name

ユーザー定義のデータ・タイプを指定する修飾された名前または非修飾の名前。 user-defined-type-name の非修飾形式は SQL ID です。 SQL ステートメントにおける非修飾の user-defined-type-name は、暗黙のうちに修飾されます。 暗黙の修飾子は、スキーマ名またはモジュール名です。どのスキーマ名またはモジュール名が使用されるかは、user-defined-type-name が出現するコンテキストで判別されます。 修飾形式は、schema-name の後にピリオドと SQL ID が続くか、module-name (schema-name で修飾することもできる) の後にピリオドと SQL ID が続きます。 ユーザー定義データ・タイプがモジュールで定義されており、同じモジュールの外部で使用される場合は、module-name で修飾する必要があります。

view-name

ビューを指定するスキーマによって修飾された名前。

wrapper-name

ラッパーを指定する ID。

XML-schema-name

XML スキーマを指定する、修飾された名前または非修飾の名前。

xsrobject-name

XML スキーマ・リポジトリー内のオブジェクトを指定する、修飾された名前または非修飾の名前。

データベース・オブジェクトの別名

別名は、SQL オブジェクトの代替名と見なすことができます。 このため、SQL ステートメントの中で SQL オブジェクトは、名前または別名で参照できます。

パブリック別名は、その名前をスキーマ名で修飾せずに常に参照できる別名です。 パブリック別名の暗黙の修飾子は SYSPUBLIC で、明示的にも指定できます。

別名は同義語とも言います。

別名は、その基になるオブジェクトを使用できる場所であればどこでも使用できます。 別名は、オブジェクトが存在していなくても作成することができます (ただし、 オブジェクトを参照するステートメントがコンパイルされる時点では存在している必要があります)。 別名チェーンの中に循環参照または反復参照がない限り、 他の別名を別名によって参照することができます。 別名で参照できるのは、同じデータベース内のモジュール、ニックネーム、順序、表、ビュー、または他の別名だけです。 CREATE TABLE または CREATE VIEW ステートメントのような、新しいオブジェクト名を指定する必要がある場合は、別名を使用できません。例えば、PERSONNEL という表別名を作成した後で、CREATE TABLE PERSONNEL... のような使い方を使用するとエラーが戻されます。 エラーが返されます。

構文図や SQL ステートメントの説明では、別名によってオブジェクトを参照するというオプションは明示的には示されません。

特定のオブジェクト・タイプ (順序など) の修飾子なしの新しい別名に、そのオブジェクト・タイプの既存のオブジェクトと同じ完全修飾名を付けることはできません。 例えば、KANDIL スキーマ内で KANDIL.ORDERID という順序名の順序別名として ORDERID は定義できません。

   SELECT * FROM PBIRD.SALES

   SELECT * FROM DSPN014.DIST4_SALES_148

許可 ID と許可名

許可 ID とは、データベース・マネージャーとアプリケーション・プロセスとの間、 またはデータベース・マネージャーとプログラム準備処理との間の接続が確立されるときに、 データベース・マネージャーが獲得する文字ストリングのことです。 これは、特権の集合を指定するものです。 ユーザーやユーザー・グループを指す場合もありますが、 この特性はデータベース・マネージャーからは制御されません。

SQL ステートメントで指定される許可名 を、 そのステートメントの許可 ID と混同してはなりません。 許可名は、種々の SQL ステートメントで使用される ID です。 許可名は、スキーマの所有者を指定するために CREATE SCHEMA ステートメントで使用されます。 許可名は、 付与または取り消しの操作の対象を指定するために GRANT および REVOKE ステートメントで使用されます。 X に特権を付与すると、それ以降、 その特権を必要とするステートメントでは、X (またはグループ あるいはロール X のメンバー) が許可 ID になるということです。

例

• ユーザー ID が SMITH であり、 またデータベース・マネージャーがアプリケーション・プロセスとの接続を確立したときに獲得した許可 ID も SMITH であるとします。 以下のステートメントは対話式に実行されます。

     GRANT SELECT ON TDEPT TO KEENE

  SMITH はこのステートメントの許可 ID です。 したがって、動的 SQL ステートメントでの CURRENT SCHEMA 特殊レジスターのデフォルト値は SMITH になり、 静的 SQL でのデフォルトの QUALIFIER プリコンパイル/BIND オプションも SMITH になります。 ステートメントを実行する権限は SMITH に対して検査されます。SMITH は、 命名規則と暗黙のオブジェクト名の修飾で説明されている修飾規則に基づく table-name 暗黙修飾子です。

  KEENE はこのステートメントで指定された許可名です。 KEENE には SMITH.TDEPT に対する SELECT 特権が付与されます。

• SMITH が管理権限を持っており、 セッション中に SET SCHEMA ステートメントが発行されない、 以下の動的 SQL ステートメントの許可 ID であるとします。

     DROP TABLE TDEPT

  これは、SMITH.TDEPT 表を削除します。

     DROP TABLE SMITH.TDEPT

  これは、SMITH.TDEPT 表を削除します。

     DROP TABLE KEENE.TDEPT

  これは、KEENE.TDEPT 表を削除します。 KEENE.TDEPT と SMITH.TDEPT は別の表であることに注意してください。

     CREATE SCHEMA PAYROLL AUTHORIZATION KEENE

  KEENE は、PAYROLL と呼ばれるスキーマを作成するステートメントで指定されている許可名です。 KEENE は、スキーマ PAYROLL の所有者であり、 CREATEIN、 ALTERIN、および DROPIN 特権が与えられ、 このような特権を他のユーザーに付与することができます。

実行時における動的 SQL の特性

BIND オプション DYNAMICRULES によって、 動的 SQL ステートメントの処理時の許可検査に使用される許可 ID が決まります。 さらにこのオプションは、 修飾されるオブジェクト参照子に使用される暗黙修飾子などの他の動的 SQL 属性や、 特定の SQL ステートメントを動的に呼び出せるかどうかも制御します。

許可 ID とその他の動的 SQL 属性の一連の値を動的 SQL ステートメント動作と呼びます。 使用可能な 4 つの動作は、実行、バインド、定義、および起動です。 以下の表で明らかなとおり、 DYNAMICRULES BIND オプションの値とランタイム環境の組み合わせで、使用する動作が決まります。 実行動作を意味する DYNAMICRULES RUN がデフォルトです。

実行動作

パッケージを実行するユーザーの許可 ID (データベースに最初に接続した ID) が、動的 SQL ステートメントの許可検査の値として使用されます。 さらにこの許可 ID は、動的 SQL ステートメント内の非修飾オブジェクト参照の暗黙的な修飾の初期値としても使用されます。

バインド動作

許可と修飾のために静的 SQL に適用されるすべての規則が、実行時に使用されます。 パッケージ所有者の許可 ID が、動的 SQL ステートメントの許可検査の値として使用されます。 パッケージのデフォルト修飾子は、動的 SQL ステートメント内の非修飾オブジェクト参照の暗黙的な修飾のために使用されます。

定義動作

定義動作が適用されるのは、 ルーチン・コンテキストで実行されるパッケージ内に動的 SQL ステートメントがあって、 しかもそのパッケージが DYNAMICRULES DEFINEBIND または DYNAMICRULES DEFINERUN でバインドされていた場合のみです。 ルーチン定義者 (ルーチンのパッケージ・バインダーではない) の許可 ID が、動的 SQL ステートメントの許可検査の値として使用されます。 さらにこの許可 ID は、そのルーチン内の動的 SQL ステートメントにおける非修飾オブジェクト参照の暗黙的な修飾にも使用されます。

呼び出し時の振る舞い

起動動作が適用されるのは、 ルーチン・コンテキストで実行されるパッケージ内に動的 SQL ステートメントがあって、 しかもそのパッケージが DYNAMICRULES INVOKEBIND または DYNAMICRULES INVOKERUN でバインドされていた場合のみです。 ルーチンが呼び出されたときに有効になっているステートメント許可 ID が、動的 SQL の許可検査の値として使用されます。 さらにこの許可 ID は、そのルーチン内の動的 SQL ステートメントにおける非修飾オブジェクト参照の暗黙的な修飾にも使用されます。 これを以下の表に要約してあります。

実行動作が適用されない場合に制限されるステートメント

バインド、定義、または起動の動作が有効になっている場合、 動的 SQL ステートメント GRANT、 REVOKE、 ALTER、 CREATE、 DROP、 COMMENT、 RENAME、 SET INTEGRITY、 SET EVENT MONITOR STATE と、 ニックネームを参照する照会は使用できません。

DYNAMICRULES オプションに関する考慮事項

バインド、定義、または起動の動作パッケージから実行される動的 SQL ステートメント内の非修飾オブジェクト参照子を修飾するのに、 CURRENT SCHEMA 特殊レジスターを使用することはできません。 これは、 CURRENT SCHEMA 特殊レジスターを変更するために SET CURRENT SCHEMA ステートメントを発行した後にもあてはまります。 レジスター値は変更されますが、使用されることはありません。

単一の接続中に複数のパッケージが参照されると、 それらのパッケージで準備されたすべての動的 SQL ステートメントは、 個々のパッケージとその使用場所である環境用に DYNAMICRULES オプションで指定されている行動をとります。

パッケージがバインド動作をとるときは、パッケージのバインド・プログラムには、 そのパッケージのユーザーには付与されるべきでない許可が付与されないように気を付けることが大切です。 動的ステートメントは、パッケージ所有者の許可 ID を使用するからです。 同様に、パッケージが定義動作をとるときは、ルーチンの定義者には、 パッケージのユーザーには付与されるべきでない許可が付与されてはなりません。

許可 ID とステートメントの準備

バインド時に VALIDATE BIND オプションを指定する場合、表やビューを扱うときに必要な特権もバインド時に存在していなければなりません。 そのような特権や参照オブジェクトが存在しない場合に、SQLERROR NOPACKAGE が有効になっていると、 バインド操作は失敗します。 SQLERROR CONTINUE オプションが指定されていると、バインド操作は正常に完了し、 エラーを生じたステートメントにはすべてフラグが付けられます。 そのようなステートメントを実行しようとすると、エラーが生じます。

VALIDATE RUN オプションでパッケージがバインドされると、通常のバインド処理はすべて完了しますが、 アプリケーションで参照される表やビューを使うのに必要な特権は、この時点では存在していなくても構いません。 必要な特権がバインドの実行時に存在しない場合に、 アプリケーション内でステートメントを初めて実行すると、必ず増分バインドが実行されます。 このときには、ステートメントに必要なすべての特権が存在していなければなりません。 必要な特権が存在しない場合、ステートメントの実行は失敗します。

実行時の許可検査は、パッケージ所有者の許可 ID を使って行われます。

列名

修飾列名

列名の修飾子としては、表名、ビュー名、ニックネーム、別名、または相関名が使用されます。

修飾子がオプションである場合、修飾子には 2 つの目的があります。 これらについては、 「あいまいさを避けるための列名修飾子」 および 「相関参照における列名修飾子」で説明されています。

相関名

   FROM X.MYTABLE Z

X.MYTABLE の相関名として Z が定義されると、 その SELECT ステートメントにおいては Z だけが X.MYTABLE インスタンスの列を参照する修飾子として使用できます。

相関名は、それが定義されているコンテキスト内でのみ、表、ビュー、ニックネーム、別名、 ネストされた表の式、表関数、またはデータ変更表参照に関連付けられます。 したがって、別の目的に使用するために、 異なるステートメントの中や同じステートメントの異なる節の中で同じ相関名を定義できます。

修飾子としての相関名は、あいまいさの回避や、相関参照の確立に利用できます。 また、表参照の単なる短縮名として利用することもできます。 この例では、X.MYTABLE と何度も入力するのを避けるためだけに Z が使用されていたとも考えられます。

相関名を表名、ビュー名、ニックネーム、または別名に対して指定する場合、 その表、ビュー、ニックネーム、または別名のそのインスタンスでの列への修飾された参照は、 その表名、ビュー名、ニックネーム、別名ではなく、相関名を使用しなければなりません。 例えば、以下の例の EMPLOYEE.PROJECT への参照は、 EMPLOYEE に対する相関名が既に指定されているため誤りです。

                                                                                          
   FROM EMPLOYEE E                                        
     WHERE EMPLOYEE.PROJECT='ABC'      * incorrect*             

   FROM EMPLOYEE E
     WHERE E.PROJECT='ABC'

   FROM EMPLOYEE E, DEPARTMENT

FROM 節の直接的な表名、ビュー名、ニックネーム、または別名は、 その FROM 節での直接的なその他の表名、ビュー名、ニックネーム、 または FROM 節の相関名のどれかと同じになる場合があります。 これにより列名参照があいまいとなり、エラー (SQLSTATE 42702) となる可能性があります。

FROM 節で相関名を使用することにより、 結果表の列に関連付けられる列名のリストを指定することもできます。 相関名の場合と同じように、このようにリストされた列名は、 照会時に列の参照に使用する必要がある列の直接的な 名前になります。 列名のリストを指定する場合、基礎表の列名は間接的な名前 になります。

次の FROM 節があるとします。

   FROM DEPARTMENT D (NUM,NAME,MGR,ANUM,LOC)

D.NUM などの修飾子の付いた参照は、 DEPTNO として表に定義されている DEPARTMENT 表の最初の列を表します。 この FROM 節を使用した D.DEPTNO の参照は、 列名 DEPTNO が間接的な列名であるため誤りです。

あいまいさを避けるための列名修飾子

関数、GROUP BY 節、ORDER BY 節、式、または検索条件のコンテキストでは、 列名は、何らかの表、ビュー、ニックネーム、 ネストされた表の式あるいは表関数の列の値を指します。 列を収容する可能性のある表、ビュー、ニックネーム、 ネストされた表の式および表関数は、 そのコンテキストのオブジェクト表 と呼ばれます。 複数の表が同じ名前の列を備えている場合があります。 列名を修飾する理由の 1 つは、列がどの表のものかを指定することにあります。 列名の修飾子は、SQL プロシージャーにおいて、 列名と SQL ステートメントで使われる SQL 変数名を区別するときにも役立ちます。

ネストされた表の式または表関数は、 FROM 節で先行する table-references をオブジェクト表と見なします。 後続の table-references はオブジェクト表とは見なされません。

表指定子

   SELECT CORZ.COLA, OWNY.MYTABLE.COLA
     FROM OWNX.MYTABLE CORZ, OWNY.MYTABLE

列を直接的な表名形式の表指定子で修飾するとき、 直接的な表名は修飾の付いた形式でも付かない形式でも使用できます。 修飾の付いた形式を使用する場合、修飾子は直接的な表名のデフォルト修飾子と同じでなければなりません。

SELECT CORPDATA.EMPLOYEE.WORKDEPT FROM EMPLOYEE

SELECT EMPLOYEE.WORKDEPT, REGEMP.WORKDEPT
  FROM CORPDATA.EMPLOYEE, REGION.EMPLOYEE REGEMP

SELECT CORPDATA.EMPLOYEE.WORKDEPT FROM EMPLOYEE

列へのあいまいな参照が生じる可能性を避けるため、 各表指定子は、特定の FROM 節の中ではユニークでなければなりません。

未定義またはあいまいな参照の回避

ユニークに定義された表指定子で列名を修飾することによって、 あいまいな参照を避けてください。 列が名前の異なる複数のオブジェクト表の中に入っている場合、 その表名を指定子として使用することができます。 また、相関名の後に続いて列名のリストを使用してオブジェクト表のいずれかの列に固有名を指定することによって、 表指定子を使用しなくてもあいまいな参照を避けることができます。

相関参照内の列名修飾子

全選択 とは、 種々の SQL ステートメントのコンポーネントとして使用される照会の 1 つの形式です。 任意のステートメントの検索条件で使用される全選択は、 副照会 と呼ばれます。 ステートメントで式として単一値を検索するのに使用される全選択は、 スカラー全選択 またはスカラー副照会 と呼ばれます。 照会の FROM 節で使用される全選択は、 ネストされた表の式 と呼びます。 検索条件、スカラー副照会、およびネストされた表の式の副照会を、 このトピックのこれ以降の部分では副照会と呼びます。

副照会にはそれ自身の副照会を収めることができます。 その副照会の中に、さらに副照会が収められていても構いません。 したがって、SQL ステートメントに副照会の階層が入ることになる場合があります。 副照会を収容する階層のエレメントは、そこに収容された副照会よりも高いレベルとされます。

階層のあらゆるエレメントには、1 つ以上の表指定子が入っています。 副照会は、階層中の自分のレベルで指定されている表の列だけでなく、 階層中のそれより前のレベルで指定されている表の列から階層の最上位で識別される表の列まで参照できます。 上位のレベルで指定される表の列への参照は、相関参照 と呼ばれます。

既存の SQL 標準規格との互換性のため、 修飾された列名と非修飾の列名のどちらも相関参照として認められています。 ただし、副照会で使用されるすべての列参照を修飾することをお勧めします。 そうしないと、同一の列名により予期しない結果が生じることがあります。 例えば、ある階層の表が相関参照として同じ列名を収めるように変更され、 ステートメントが再度作成処理された場合、 新たな参照は変更された表に対して適用されます。

副照会内の列名が修飾されているときは、 修飾されているその列名が出現するのと同じ副照会から探索が始まり、 修飾子に一致する表指定子が見つかるまで、 階層の上位へ向かって階層の各レベルの探索が続けられます。 該当するものが見つかると、その表に指定の列があるかどうかが調べられます。 列名を収容しているレベルより高いレベルで表が見つかった場合、 これは表指定子が見つかったレベルに対する相関参照となります。 ネストされた表の式の全選択より上の階層を探索するためには、 ネストされた表の式の前にオプションの TABLE キーワードを指定しなければなりません。

副照会に収容されている列名が修飾されていないときは、 その列名が出現するのと同じ副照会から始めて、 階層の各レベルで参照されている表が探索され、 一致する列名が見つかるまで、階層の上位へ向かって探索が続けられます。 列名を収容しているレベルより高いレベルの表で列が見つかった場合は、 その列を収めた表が見つかったレベルに対する相関参照となります。 列名が、特定のレベルの 2 つ以上の表で見つかった場合は、 参照はあいまいになり、エラーと見なされます。

同じ表、ビュー、またはニックネームが、 多くのレベルで指定されていることがあるため、 表指定子としては固有の相関名を使用するようお勧めします。 T が 2 つ以上のレベルで表の指定に使用される場合 (T は表名自体か重複の相関名)、T.C は、T.C の入った副照会を最も直接的に収容するように T が使用されているレベルを参照することになります。 上位レベルへの相関が必要な場合、ユニークな相関名を使用する必要があります。

相関参照 T.C は、2 つの検索条件が、検索条件 1 が副照会で、 検索条件 2 が上位のレベルでそれぞれ適用されている T の行またはグループでの C の値を識別します。 条件 2 が WHERE 節で使用される場合、副照会は条件 2 が適用される行ごとに評価されます。 条件 2 が HAVING 節で使用される場合、副照会は条件 2 が適用されるグループごとに評価されます。

   SELECT EMPNO, LASTNAME, WORKDEPT
     FROM EMPLOYEE X
     WHERE SALARY < (SELECT AVG(SALARY)
                       FROM EMPLOYEE
                       WHERE WORKDEPT = X.WORKDEPT)

   DELETE FROM DEPARTMENT THIS
      WHERE NOT EXISTS(SELECT *
                         FROM EMPLOYEE
                         WHERE WORKDEPT = THIS.DEPTNO)

変数の参照

SQL ステートメントの変数 は、SQL ステートメントの実行時に変更が可能な値を指定します。 SQL ステートメントで使用される変数にはさまざまな種類があります。

ホスト変数

ホスト変数は、ホスト言語のステートメントによって定義されます。 ホスト変数の参照方法について詳しくは、 ホスト変数への参照を参照してください。

遷移変数

遷移変数はトリガーで定義され、列の古い値または新しい値のいずれかを参照します。 遷移変数の参照方法について詳しくは、 CREATE TRIGGER ステートメントを参照してください。

SQL 変数

SQL 変数は、SQL 関数、SQL メソッド、SQL プロシージャー、トリガーの SQL コンパウンド・ステートメント、または動的 SQL ステートメントで定義されます。 SQL 変数について詳しくは、 SQL パラメーター、SQL 変数、およびグローバル変数への参照を参照してください。

グローバル変数

グローバル変数は CREATE VARIABLE ステートメントによって定義されます。 グローバル変数について詳しくは、 CREATE VARIABLE および SQL パラメーター、SQL 変数、およびグローバル変数への参照を参照してください。

モジュール変数

モジュール変数は、ALTER MODULE ステートメントで、ADD VARIABLE 操作または PUBLISH VARIABLE 操作を使用して定義されます。 モジュール変数について詳しくは、 ALTER MODULE ステートメントを参照してください。

SQL パラメーター

SQL パラメーターは、CREATE FUNCTION、CREATE METHOD、または CREATE PROCEDURE ステートメントによって定義されます。 SQL パラメーターについて詳しくは、 SQL パラメーター、SQL 変数、およびグローバル変数への参照を参照してください。

パラメーター・マーカー

パラメーター・マーカーは動的 SQL ステートメントで指定されます。 ステートメントが静的 SQL ステートメントであれば本来、これに代わってホスト変数が指定されます。 動的 SQL ステートメントの処理中に値をパラメーター・マーカーと関連付けるために、 SQL 記述子またはパラメーター・バインディングが使用されます。 パラメーター・マーカーについて詳しくは、 パラメーター・マーカーを参照してください。

ホスト変数の参照

これらは、SQL ステートメントで参照されています。 ホスト変数はホスト言語のステートメントによって直接定義されるか、 または SQL 拡張機能を使って間接的に定義されます。

SQL ステートメント内のホスト変数は、 ホスト変数宣言規則に従ってプログラム内に記述されたホスト変数を識別する必要があります。

SQL ステートメントで使用されるすべてのホスト変数は、REXX を除くすべてのホスト言語の SQL DECLARE セクションで宣言する必要があります。 SQL DECLARE セクションで宣言されている変数と同じ名前の変数を、 SQL DECLARE セクションの外部で宣言することはできません。 SQL DECLARE セクションは、BEGIN DECLARE SECTION で始まり、 END DECLARE SECTION で終わります。

メタ変数の host-variable (ホスト変数) が構文図の中で使われる場合、 それはホスト変数への参照を示します。 SET 変数ステートメント内か、FETCH、SELECT INTO、または VALUES INTO ステートメントの INTO 節内のターゲット変数としてのホスト変数は、行の中の列の値または式の値が割り当てられるホスト変数を識別するものです。 その他のコンテキストでのホスト変数は、 アプリケーション・プログラムからデータベース・マネージャーに渡される値を指定します。

構文図におけるメタ変数 host-variable (ホスト変数) は、 一般に以下のように展開されます。

各 host-identifier (ホスト ID) は、 ソース・プログラムの中で宣言される必要があります。 2 番目のホスト ID で指定される変数は、 データ・タイプが短精度整数のものでなければなりません。

最初の host-identifier (ホスト ID) は、 メイン変数 を指定します。 演算に応じて、このホスト ID はデータベース・マネージャーに値を提供したり、 またはデータベース・マネージャーから提供される値を受け取ったりします。 入力ホスト変数は、ランタイム・アプリケーション・コード・ページの値を提供します。 出力ホスト変数には、データが出力アプリケーション変数にコピーされるときに、 必要に応じてランタイム・アプリケーション・コード・ページに変換される値が提供されます。 指定されるホスト変数は、同じプログラム内で入力変数と出力変数の両方として機能できます。

2 番目の host-identifier (ホスト ID) は、その標識変数 を示します。 標識変数は、通常標識変数と拡張標識変数の 2 つの書式で表示されます。

拡張標識変数は要求された場合のみ使用可能になり、要求されない場合は標識変数はすべて通常標識変数になります。 拡張標識変数には、通常標識変数と比較して、NULL および NULL 以外の値を使用できる場所に関する追加の制約事項はありません。 ホスト構造の標識構造内で拡張標識変数の値を使用することに対する制約事項はありません。 デフォルトおよび未割り当ての拡張標識変数の値が許可される場所に関する制約事項は、ホスト・アプリケーション内で示されている方法にかかわらず、一様に適用されます。 デフォルトおよび未割り当ての拡張標識変数の値は、限定された指定済みの使用法に限り表示できます。 単一のホスト変数または明示的にキャストされる (列に割り当てられる) ホスト変数のみを含む式で表示できます。 出力標識変数値が拡張標識変数になることはありません。

拡張標識変数が使用可能な場合は、0 (ゼロ) または正の標識変数値の使用に関する制約事項はありません。 しかし、-1 から -7 までの範囲外にある負の標識変数値を入力にすることはできません (SQLSTATE 22010)。 使用可能な場合、デフォルトおよび未割り当ての拡張標識変数の値を、サポートされていないコンテキストで表示することはできません (SQLSTATE 22539)。

拡張標識変数が使用可能な場合は、負の拡張標識の値を持つホスト変数に関する、割り当ておよび比較におけるデータ・タイプ妥当性検査の規則は緩和されます。 値が NULL、デフォルト、または未割り当てのホスト変数には、データ・タイプの割り当ておよび比較の妥当性検査の規則は実施されません。

例えば、:HV1:HV2 を使用して挿入値または更新値を指定する場合に、 HV2 が負であると、指定される値は NULL 値になります。 HV2 が負でない場合、指定される値は HV1 の値です。

同様に、:HV1:HV2 が FETCH、SELECT INTO、または VALUES INTO ステートメントの INTO 節に指定され、しかも戻された値が NULL 値である場合には、HV1 は変更されず、HV2 は負の値に設定されます。 dft_sqlmathwarn を yes にしてデータベースが構成されている場合 (または静的 SQL ステートメントのバインドの過程で構成されていた場合)、HV2 を -2 にするこができます。 HV2 が -2 である場合、HV1 の数値タイプへの変換エラー、 または HV1 の値を判別するために使用される演算式の評価エラーにより、 HV1 の値を戻すことができません。 戻された値が NULL 値でない場合は、その値が HV1 に割り当てられ、 HV2 はゼロに設定されます (ただし、 HV1 への割り当てに非 LOB ストリングのストリング切り捨てが必要になる場合を除きます。 この場合 HV2 はストリングの元の長さに設定されます)。 割り当て時に時刻の秒の部分の切り捨てが必要な場合、HV2 は秒数に設定されます。

2 番目のホスト ID が省略されている場合は、ホスト変数は標識変数を持たないことになります。 ホスト変数参照 :HV1 によって指定される値は、常に HV1 の値であり、変数に NULL 値を割り当てることはできません。 したがって、この形式は、対応する列で NULL 値を使えない場合以外は、INTO 節では使用しないでください。 この形式が使用された場合に、列に NULL 値が入っていると、 データベース・マネージャーは実行時にエラーを生成します。

ホスト変数を参照する SQL ステートメントは、 対象のホスト変数の宣言の範囲内にある必要があります。 カーソルの SELECT ステートメントで参照されるホスト変数の場合、 この規則は DECLARE CURSOR ステートメントではなく、OPEN ステートメントに適用されます。

例

  SELECT PROJNAME, PRSTAFF, MAJPROJ
    INTO :PNAME, :STAFF :STAFF_IND, :MAJPROJ :MAJPROJ_IND
    FROM PROJECT
    WHERE PROJNO = 'IF1000'

動的 SQL における変数

   INSERT INTO DEPARTMENT
     VALUES (:HV_DEPTNO, :HV_DEPTNAME, :HV_MGRNO, :HV_ADMRDEPT)

   INSERT INTO DEPARTMENT VALUES (?, ?, ?, ?)

   INSERT INTO DEPARTMENT 
     VALUES (:DEPTNO, :DEPTNAME, :MGRNO, :ADMRDEPT)

   EXECUTE DYNSTMT 
     USING :HV_DEPTNO, :HV_DEPTNAME :HV_MGRNO, :HV_ADMRDEPT

LOB 変数の参照

通常の BLOB、CLOB、および DBCLOB 変数、LOB ロケーター変数 ( LOB ロケーター変数への参照を参照)、および LOB ファイル参照変数 ( LOB ファイル参照変数への参照を参照) は、すべてのホスト言語で定義できます。 LOB が使用可能な場合、構文図の host-variable (ホスト変数) という用語は、 通常のホスト変数、ロケーター変数、またはファイル参照変数を指します。 これらはネイティブのデータ・タイプではないため、 SQL 拡張機能が使用され、それぞれの変数を表現するのに必要なホスト言語構成をプリコンパイラーが生成します。 REXX の場合、LOB はストリングにマップされます。

ラージ・オブジェクト値全体を保持できるほど大きい変数を定義できる場合もあります。 このような場合で、サーバーからのデータ転送を据え置いてもパフォーマンス上のメリットが期待できない場合は、 ロケーターを使用する必要はありません。 しかし、ホスト言語やスペースの制限により、一時ストレージにラージ・オブジェクト全体を一度に保管できない場合もよくありますし、またはパフォーマンス上の利点のために、ラージ・オブジェクトをロケーターを介して参照し、そのオブジェクトの一部をホスト変数へ SELECT INTO により挿入したり、ホスト変数から更新したりすることにより、一度にラージ・オブジェクトの一部分だけが含まれるようにすることができます。

LOB ロケーター変数の参照

ロケーター変数 は、 アプリケーション・サーバーで LOB 値を表すロケーターの入ったホスト変数です。

SQL ステートメントにおけるロケーター変数は、 ロケーター変数の宣言規則に従ってプログラムに記述されたロケーター変数を識別したものでなければなりません。 これは常に SQL ステートメントによって間接的に行われます。

構文図で locator-variable (ロケーター変数) の語が使用される場合、 それはロケーター変数への参照を表します。 メタ変数 locator-variable (ロケーター変数) は、 host-variable (ホスト変数) の場合と同じく、 host-identifier (ホスト ID) を組み込めるように拡張できます。

他のすべてのホスト変数と同様に、 ラージ・オブジェクトのロケーター変数にも標識変数を対応させることができます。 ラージ・オブジェクトのロケーター・ホスト変数に対応する標識変数は、 他のデータ・タイプの標識変数と同じように動作します。 データベースから NULL 値が戻されると、標識変数が設定され、 ロケーター・ホスト変数は変更されません。 つまり、ロケーターが NULL 値を指すことはないということです。

現時点で何の値も表していないロケーター変数が参照されると、エラー (SQLSTATE 0F001) になります。

トランザクションのコミット時、またはトランザクションの終了時に、 そのトランザクションが獲得していたロケーターはすべて解放されます。

LOB ファイル参照変数の参照

BLOB、CLOB、および DBCLOB のファイル参照変数は、 LOB の直接のファイル入出力に使用されるもので、すべてのホスト言語で定義可能です。 これらはネイティブのデータ・タイプではないため、 SQL 拡張機能が使用され、それぞれの変数を表現するのに必要なホスト言語構成をプリコンパイラーが生成します。 REXX の場合、LOB はストリングにマップされます。

LOB ロケーターが LOB バイトを収容するのではなく LOB バイトを表すのと同じように、 ファイル参照変数はファイルを収容するのではなくファイルを表します。 データベースの照会、更新、および挿入では、 ファイル参照変数を使用して 1 つの列値を保管したり検索したりすることができます。

他のすべてのホスト変数と同様に、ファイル参照変数にも標識変数を対応させることができます。

出力ファイル参照変数の例 (C の場合)

   EXEC SQL BEGIN DECLARE SECTION
      SQL TYPE IS CLOB_FILE  hv_text_file;
      char  hv_patent_title[64];
   EXEC SQL END DECLARE SECTION

   EXEC SQL BEGIN DECLARE SECTION
      /* SQL TYPE IS CLOB_FILE  hv_text_file; */
      struct {
          unsigned long  name_length; //  File Name Length
          unsigned long  data_length; //  Data Length
          unsigned long  file_options; // File Options
          char           name[255];   // File Name
      } hv_text_file;
      char  hv_patent_title[64];
   EXEC SQL END DECLARE SECTION

   strcpy(hv_text_file.name, "/u/gainer/papers/sigmod.94");
   hv_text_file.name_length = strlen("/u/gainer/papers/sigmod.94");
   hv_text_file.file_options = SQL_FILE_CREATE;

   EXEC SQL SELECT content INTO :hv_text_file from papers
        WHERE TITLE = 'The Relational Theory behind Juggling';

入力ファイル参照変数の例 (C の場合)

   strcpy(hv_text_file.name, "/u/gainer/patents/chips.13");
   hv_text_file.name_length = strlen("/u/gainer/patents/chips.13");
   hv_text_file.file_options = SQL_FILE_READ:
   strcpy(:hv_patent_title, "A Method for Pipelining Chip Consumption");

   EXEC SQL INSERT INTO patents( title, text )
            VALUES(:hv_patent_title, :hv_text_file);

構造化タイプ・ホスト変数の参照

構造化タイプ変数は、FORTRAN、REXX、および Java を除くすべてのホスト言語で定義できます。 これらはネイティブのデータ・タイプではないため、 SQL 拡張機能が使用され、それぞれの変数を表現するのに必要なホスト言語構成をプリコンパイラーが生成します。

他のすべてのホスト変数と同様に、構造化タイプ変数にも標識変数を対応させることができます。 構造化タイプ・ホスト変数に対応する標識変数は、 他のデータ・タイプの標識変数と同じように動作します。 データベースから NULL 値が戻されると、標識変数が設定され、 構造化タイプ・ホスト変数は変更されません。

ホスト変数の代わりにパラメーター・マーカーを使用している場合、 SQLDA に適切なパラメーター・タイプの特性を指定する必要があります。 この場合、SQLDA には SQLVAR 構造のセットが「2 つ」必要です。また、副次 SQLVAR の SQLDATATYPE_NAME フィールドには、構造化タイプのスキーマおよびタイプ名を入れなければなりません。 SQLDA 構造でスキーマを省略すると、エラーが発生します (SQLSTATE 07002)。

例

   EXEC SQL BEGIN DECLARE SECTION;
         static SQL
            TYPE IS POLYGON AS BLOB(1M)
            hv_poly, hv_point;
   EXEC SQL END DECLARE SECTION;

SQL パス

SQL パスは、スキーマ名の順序リストです。 データベース・マネージャーは SQL パスを使用して、CREATE、DROP、COMMENT、GRANT、または REVOKE ステートメントのメイン・オブジェクト以外として任意のコンテキストに出現する、非修飾のデータ・タイプ名 (組み込みタイプおよび特殊タイプ)、グローバル変数名、モジュール名、関数名、およびプロシージャー名のスキーマ名を解決します。 詳しくは、『非修飾オブジェクト名の修飾』を参照してくさい。

例えば、SQL パスが SYSIBM とします。 SYSFUN、SYSPROC、SYSIBMADM、SMITH、 XGRAPHICS2、および非修飾特殊タイプ名 MYTYPE が指定されていた場合、データベース・マネージャーはスキーマ SYSIBM で MYTYPE を最初に探し、その後 SYSFUN、SYSPROC、SYSIBMADM、SMITH、および XGRAPHICS2 の順に検索します。

非修飾オブジェクト名の修飾

非修飾オブジェクト名は、暗黙的に修飾されます。 名前の修飾規則は、名前が識別するオブジェクトのタイプによって異なります。

非修飾の別名、索引、パッケージ、シーケンス、表、トリガー、およびビューの名前

非修飾の別名、索引、パッケージ、シーケンス、表、トリガー、およびビューの名前は、デフォルト・スキーマによって暗黙的に修飾されます。

静的 SQL ステートメントの場合、デフォルト・スキーマは、そのステートメントを含む関数、パッケージ、プロシージャー、またはトリガーが作成された際に指定されたデフォルト・スキーマです。

動的 SQL ステートメントの場合のデフォルト・スキーマは、アプリケーション・プロセスに指定されたデフォルト・スキーマです。 デフォルト・スキーマは、SET SCHEMA ステートメントを使用することにより、アプリケーション・プロセスに指定できます。 デフォルト・スキーマを明示的に指定しないと、ステートメントの許可 ID がデフォルト・スキーマになります。

非修飾のユーザー定義タイプ、関数、プロシージャー、グローバル変数、モジュール、および固有の名前

新しい SYSIBM 関数は、同じ名前を持つ非修飾のユーザー定義関数をオーバーライドする

既存のユーザー定義関数またはユーザー定義プロシージャーが、新しい組み込み関数や SQL 管理ルーチンと同じ名前およびシグニチャーを持つことがあります。 このような場合、動的 SQL ステートメント内のそれらの関数またはルーチンへの非修飾参照によって実行されるのは、組み込み関数や SQL 管理ルーチンであって、ユーザー定義のものではありません。

デフォルトの SQL パスには、USER 特殊レジスターの値であるスキーマ名の前に、スキーマ SYSIBM、SYSFUN、SYSPROC、および SYSIBMADM が含まれます。 SET PATH ステートメントまたは FUNCPATH バインド・オプションで明示的に SQL パスが設定される場合にも、これらのシステム・スキーマが SQL パスに含められます。 関数解決およびプロシージャー解決の際に、SYSIBM、SYSFUN、SYSPROC、および SYSIBMADM スキーマ内の組み込み関数および SQL 管理ルーチンは、ユーザー定義関数とユーザー定義プロシージャーよりも前に検出されます。

この変更は、パッケージ内の静的 SQL や、ビュー、トリガー、SQL 関数といった SQL オブジェクトには影響を及ぼしません。 これらのケースでは、パッケージの明示的バインドまで、あるいは SQL オブジェクトのドロップと作成まで、ユーザー定義の関数やプロシージャーが引き続き実行されます。

新しい SYSIBM 関数の代わりに同名の非修飾のユーザー定義ルーチンを実行するには、実行前に、そのユーザー定義ルーチンを名前変更するか名前を完全修飾してください。 あるいは、SQL パス内で、組み込み関数および SQL 管理ルーチンが存在するスキーマの前に、ユーザー定義ルーチンが存在するスキーマを配置します。 ただし、SQL パス内でスキーマをレベル上げすると、システム・スキーマが最初に考慮されるため、すべての組み込み関数および SQL 管理ルーチンの解決時間が増加します。

修飾オブジェクト名の解決

予約済みパッケージ名

システムが使用するために、特定のパッケージ名セットが明示的に予約されています。 これらの名前のシステム使用との競合を避けるために、これらのパッケージ名をどのアプリケーションでも使用しないことを推奨します。