DB2 for i 7.2の機能とその楽しさ:パート3
このシリーズの第 2 ヒントでは、DB2 for i 7.2 で導入された KEEP IN MEMORY 節、AUTONOMOUS PROCEDURE 節、CHECK CONSTRAINT VIOLATION 節の 3 つの機能を調べました。このヒントは、残っているわずかなその他の機能を順不同で探ることで、この勢いを保つことが目的です。
TABLE_NAME スカラー関数と TABLE_SCHEMA スカラー関数
これら 2 つの新しい関数は SYSIBM スキーマに存在し、別名に関する基本情報を調べる場合に使用します。別名が WASHINGTON と言う名前のシステムの DB2 リモート・システム・テーブルで定義されているとしましょう。
CREATE ALIAS DATALIB.WASHINGTON_TRANSACTIONS FOR
WASHINGTON.ADVWORKS.TRANSACTIONHISTORY;
以下の VALUES ステートメントは、これら新しい関数を使用して、別名が構築されたテーブルやビューに関する名前とスキーマ情報を戻します。
VALUES (
SYSIBM.TABLE_NAME('WASHINGTON_TRANSACTIONS','DATALIB'),
SYSIBM.TABLE_SCHEMA('WASHINGTON_TRANSACTIONS','DATALIB')
);
クエリーは値 TRANSACTIONHISTORY、ADVWORKS を返します。言い換えれば、クエリーは、別名の元になっているテーブル/ビューおよびスキーマを示しています。
カタログ (別名 RDB) 名をプルアウトするのに、IBM は TABLE_CATALOG 関数も作成しておくべきだったようです。一部の人は決してハッピーではないと思います。ちなみに、別名の基礎となる基本情報 (カタログ/RDB 名を含む) も QSYS2.SYSTABLES カタログ・ビューから取得できます。
EXECUTE IMMEDIATE と PREPARE を指定した SQL 式
これは、小規模な機能強化の 1 つで、重宝するでしょう。これらの SQL ステートメント (EXECUTE IMMEDIATE および PREPARE) は、ホスト変数に加えて、定数または SQL 式を承認できるようになりました。かつては、定数は指定できませんでした。
例 (RPG 組み込み):
EXEC SQL
EXECUTE IMMEDIATE
'UPDATE COMPANY
SET CUR_AR_BALANCE='||VARCHAR(:AR_BALANCE,30)||'
WHERE COMPANY_ID='||VARCHAR(:CUSTOMER_ID,10);
EXEC SQL
EXECUTE IMMEDIATE 'DROP TABLE ' || :MYTABLE;
EXECUTE IMMEDIATE は、HLL プログラム、SQL トリガー、または SQL ルーチンに組み込むことしかできない点に注意してください。動的には発行できません。
GRANT と REVOKE でグループ・プロファイルを使用する
GRANT ステートメントと REVOKE ステートメントはわずかな構文変更ができるようになり、どのタイプのプロファイル (ユーザーまたはグループ) を参照中か、明確にする場合に使用できます。
-- ユーザー・プロファイルの場合
GRANT ALL ON DEV.QRPGLESRC TO USER JOE
-- グループ・プロファイルの場合
GRANT ALL ON DEV.QRPGLESRC TO GROUP DEV_GROUP
ユーザーまたはグループのキーワードを指定し、指定されたプロファイルがそのタイプと一致しない場合、DB2 は SQL0159 &1 in *N not correct type (SQL0159 *N 中の &1 が正しいタイプではない) というエラーを吐き出します。GRANT および REVOKE を指定したグループ・プロファイル権限割り当ては、以前 DB2 for i バージョンでは許可されていましたが、現在は開発者または DBA は、どのタイプのプロファイルを意図しているか示し、意図したプロファイル・タイプが正しいことを、システムに検証させるオプションがあります。
TRANSFER OWNERSHIP ステートメント
これは自分の SQL ツールボックスで持ちたい項目の 1 つです。このステートメントは、SQL テーブルの所有権を指定されたユーザー・プロファイルに変更します。
TRANSFER OWNERSHIP OF TABLE ADVWORKS.ITEMS
TO USER QPGMR PRESERVE PRIVILEGES
この場合、既存の所有者がオブジェクトに対するカレントの特権を保持し続けます。しかし、次の例では、既存の所有者はその特権を失っています。
TRANSFER OWNERSHIP OF INDEX ADVWORKS.IDX_SALES_ORDER
TO USER QPGMR REVOKE PRIVILEGES
オブジェクトへの排他的アクセスが必要です。そうしないと、ステートメントは (グループ PTF レベル 1 で) SQL0901 SQL system error (SQL0901 SQL システム・エラー) で失敗します。ジョブ・ログを確認すると、真のエラー CPF3202 File &1 in library &2 in use (CPF3202 ライブラリー &2 のファイル &1 が使用中です) がわかります。
TRANSFER OWNERSHIP を SQL ステートメントにすると、アプリケーションを保守する場合に、 IBM i OS コマンド Change Object Owner (CHGOBJOWN) を使用する必要性が緩和されます。他の DB2/RDBMS プラットフォームの管理者は楽に IBM i に調整できるため、これは優れています。
今のところ、このステートメントは、テーブル、ビュー、インデックスにのみ有効です。ストアード・プロシージャーやデータ域など他のオブジェクトの所有者変更は、依然として IBM i Change Object Owner (CHGOBJOWN) コマンドで行う必要があります。
VERIFY_GROUP_FOR_USER 関数
この関数により、現行ユーザーが、あるグループ・プロファイルに属している場合に、アプリケーションをテストできます。第 1 パラメーターは (SESSION_USER, USER または CURRENT_USER で指定された) 現行ユーザーで、第 2 パラメーターは当該グループ・プロファイルです。結果は 0 または 1 です。
-- 現行ユーザーがグループ・プロファイル QGPMR に属している場合、1 を返します。
VALUES (VERIFY_GROUP_FOR_USER(SESSION_USER,'QPGMR'));
この関数により、現行プロファイルだけではなく、グループ・メンバーシップに対して、あらゆるユーザー・プロファイルをテストできたら素晴らしかっただろうと思います。この関数は新しい行列アクセス制御 (RCAC) 機能で使用する目的で設計されているため、その制限にはおそらく理由があるのでしょう。
LPAD 関数と RPAD 関数
LPAD (左詰め) および RPAD (右詰め) 関数は、スペース (デフォルト) またはストリング式で、式を左または右に詰める場合に使用します。これらの関数には 3 つのパラメーターが指定できます (3 番目はオプション)。
- 詰める式
- 長さ
- 埋め込み式 (オプション)
以下の LPAD 式を使用して、小切手の金額を印刷する場合の貨幣価値をフォーマットします。
VALUES (LPAD(1235.25,15,'*'))
文字長が 15 の左詰め値を返します。
********1235.25
同様に、以下の RPAD 式を見てください。
VALUES (RPAD('1235.25',15,'*'))
文字長が 15 の右詰め値を返します。
1235.25********
これらの埋め込み式は特に、エクスポート・ファイルの固定幅列を構築する場合に便利です。
まだ IBM i 7.2 を使用していない場合は、次のようにして、これらの関数を非常に簡単にエミュレートできます。
VALUES (RIGHT(REPEAT('*',15) || '1235.25',15)); -- LPAD のエミュレート
VALUES (LEFT('1235.25'||REPEAT('*',15),15)); -- RPAD のエミュレート
著者のメモ: DB2 for i グループ・レベル 1 では、これらの関数はエラー SQL0440 (Routine LPAD in *N not found with specified parameters. パラメーターを指定した *N のルーチン LPAD が見つかりません) を返します。
お疲れ様です
まだ完全には終わっていません。今後のヒントでは、 DB2 for i 7.2 の機能の巨人: 行列アクセス制御 (別名 RCAC) についてお話しします。
