ストアド・プロシージャーとは ?
ストアド・プロシージャーとは SQL文による実行機能をプログラマブルに補完して
拡張できる機能のことです。
例えば、SQL文だけでは実行できる機能にも限界があり、
実行のパフォーマンスにも問題があります。
そこで SQL結果セットを作成できるような RPG、COBOL や C/400 を
予め作成して保管しておいて、これを呼び出すようにするとパフォーマンスにも優れた
柔軟性に富む処理を行うことができるようになります。
これらの予め登録されたプロシージャーのことをストアド・プロシージャーと呼びます。
ストアド・プロシージャーが動作する条件
ストアド・プロシージャーが動作するためには
RDBディレクトリーとして特殊値 *LOCAL
と定義されている
ディレクトリーが登録されている必要があります。
このことは WRKRDBDIRE
(RDB ディレクトリー項目の処理)コマンドによって
下記のように確認することができます。
解説
クライアントからの要求を処理するプロシージャー
元々はストアド・プロシージャーは PCクライアントの ODBCドライバーからの
要求に応えて SQL結果セットを戻すことが本来の機能でした。
ODBCドライバーの処理
今ではストアド・プロシージャーは単に ODBCドライバーの要求を処理するための
サーバー・プログラムであるという役割となっています。
利用方法
ストアド・プロシージャーは Web での利用方法として
- 動的なコンボボックス
- 動的な POPUPウィンドウ
- Webアプリケーション
に利用されています。
動的なコンボボックスや POPUPウィンドウにストアド・プロシージャーを登録しておいて
DDSソースにストアド・プロシージャーの名前を登録するだけでストアド・プロシージャーを
利用できるようになります。
このことは非常に便利な機能拡張となります。
従来型の 5250アプリケーションでは POPUPコード検索App を追加するには
POPUPコード検索プログラムを新規に開発して、それをまた親アプリケーションの
ひとつひとつにコーディングを追加する必要がありました。
しかし、コード検索用のストアド・プロシージャーは、プロシージャーを開発すれば
親アプリケーションの画面DDS に登録するだけで済みます。
ストアド・プロシージャー用の画面を開発する必要もありませんし、
親プログラムを一切、変更する必要もありません。
このように従来のアプリケーションを開発するのとは全く異なる簡単な手法だけで
機能を大幅に拡張することができるようになります。
またクライアント / サーバー型の適用業務で既に開発して使用していたストアド・プロシージャーは
Webアプリケーションのサーバー側のエンジンとして再利用することができます。
ストアド・プロシージャーの種類
ストアド・プロシージャーには
- SQLストアド・プロシージャー
- PGMストアド・プロシージャー
- Query/400ストアド・プロシージャー
の 3種類があります。
最初の SQLストアド・プロシージャーとは SQL文を登録しておいて、
この SQL文から生成されるプロシージャーのことを意味します。
SQLストアド・プロシージャー
SQLストアド・プロシージャー は次のようにして開発 / 登録します。
最初に QSQLSRC などのソース・ファイルに次のような SQLステートメントを登録します。
QTRSRC/QSQLSRC(P1)
CREATE PROCEDURE QTROBJ/P1() LANGUAGE SQL DYNAMIC RESULT SETS 1 BEGIN DECLARE C1 CURSOR FOR SELECT TACODE, TTNAMJ FROM QTRFIL/TANTOM ORDER BY TACODE; OPEN C1; RETURN; END;
解説
初めの CREATE PROCEDURE QTROBJ/P1()
によって、ライブラリーQTROBJ
に P1
という
名前でプロシージャーを登録します。
実行する SQL文 SELECT TACODE, TTNAMJ FROM QTRFIL/TANTOM ORDER BY TACODE;
を
登録します。
RUNSQLSTM でコンパイル
次にこの SQLソースを RUNSQLSTM
で実行すると、この SQL文を実行するプロシージャーP1
が
ライブラリー : QTROBJ
に登録されます。
実際には上記の SQL文から C/400ソースが内部的に生成されてコンパイルされ、
生成されてできたプログラムがプロシージャーとして登録されることになります。
SQL文からの自動生成に頼るのではなくユーザーが SQL結果セットを
ODBCドライバーに戻すプログラムを作成するプロシージャーのことを次に紹介する
PGMストアド・プロシージャーと呼びます。
RUNSQLSTM でエラーのときは ?
RUNSQLSTM実行でエラーが発生してプロシージャーを作成できなかったときは、
入力やタイプ・ミスがないかを慎重に検討してソースを読み直してください。
- 単純なスペル・ミス
- セミコロン(
;
)などの漏れ - その他
対話式ジョブで RUNSQLSTM を実行したときであっても
印刷スプールに必ず RUNSQLSTM のコンパイル・リストと
エラー・リストの 2部が出力されていますのでそれを参照してください。
必ず ODBCドライバーを使ってテストしてください
ストアド・プロシージャーを作成したら必ず次の項で説明される
「ODBCドライバー
」を使ってテストした正しい結果が得られるかどうかご確認ください。
またストアド・プロシージャーの動作がおかしいと感じた場合も
ODBCドライバーによる確認をお奨めします。
PGMストアド・プロシージャー
SQLストアド・プロシージャーではユーザーは SQL文だけを記述して後は RUNSQLSTM
コマンドによって
プロシージャーを実行するプログラムは内部で自動生成されるようになっていましたが
PGMストアド・プロシージャーでは実行プログラムはユーザーがソースから作成することになります。
PGMストアド・プロシージャーは開発は概ね、次の手順に従ってなされます。
-
SQLRPGI
などの SQLバインドの RPG や COBOL の作成 & コンパイル - 対話式SQL または SQLソースに
CREATE PROCEDURE
文を仕込んでRUNSQLSTM
で実行
です。
次の「ユーザー独自のプログラムの作成」では実際の RPG によるストアド・プロシージャーの開発方法を
具体的な事例に基づいて解説します。
Query/400ストアド・プロシージャー
Query/400ストアド・プロシージャーとは Query定義 (*QRYDFN
) から生成される
ストアド・プロシージャーです。
既存のQuery/400定義(*QRYDFN
)から
ストアドプロシージャーの作成 (CRTSQLPRC) 選択項目を入力して,実行キーを押してください。 ストアド・プロシージャー . . . > P1 名前 , *NONE ライブラリー . . . . . . . . > QTROBJ 名前 , *LIBL タイプ . . . . . . . . . . . . > *QRYDFN *SQL, *RPG, *COBOL.. プログラムまたは QUERY . . . . > QRY001 名前 , *PROC ライブラリー . . . . . . . . > QTROBJ 名前 , *LIBL 既存のプロシージャーの置換え > *YES *NO, *YES
のようにして CRTSQLPRC
によって ストアド・プロシージャーを生成することができます。
Query/400を使えば複雑な選択条件であっても対話式の Query によって簡単に作れて わかりやすく保守も容易になります。
リモート・ロケーションが *LOCAL として定義されているRDBディレクトリーは
一般には i5/OS の導入時にシステムによって、
'S'+(シリアル番号)
の形式名で追加されています。ストアド・プロシージャーを起動する ODBCドライバーは、
この
*LOCAL
として定義されているRDBディレクトリーを探してバインドします。一般的には事前に
*LOCAL
の RDBディレクトリーが登録されていますが何らかの事情で登録がない場合は「1=追加」(ADDRDBDIRE:RDB ディレクトリー項目の追加)
によって
*LOCAL
の RDBディレクトリーを登録してください。