ストアドプロシージャーという表現は、SQLベースのサーバーの世界に由来しています。クライアントワークステーションがSQLベースのサーバーに要求を送信する時、実際にはSQLサーバーに対してSQL言語で記述されたテキストを送信します。この要求は、実行される前にSQLサーバー上で解釈されます。要求のソースコードのサイズが大きく、1回のセッション中に要求が何度も送信される場合には、送られる要求の回数が多いほど、ネットワーク経由でソースコードを送信、解析し、解釈する時間が長くなることは明らかです。

そこでネットワーク経由で要求を送信し、解析および解釈を一度だけ行い、クライアントワークステーションから受信するたびにこれを実行する方法を探しました。この解決方法は、要求のソースコード (つまりプロシージャー) をサーバー側に保存し、クライアントワークステーションには実行するプロシージャーの名前だけで構成される要求を送らせることでした。結果的に、このプロシージャーはサーバー上にストアされるため、"ストアドプロシージャー"という用語になっています。

SQLベースのストアドプロシージャーは、クライアントワークステーションから引数を受信し、実現するタスクを (同期的または非同期的に) 実行し、最終的に結果をクライアントワークステーションに戻すことができるプロシージャーであるということに注意してください。クライアントワークステーションがストアドプロシージャーの実行を開始すると、ある程度サーバーマシンにコードの実行を任せます。

4D Server では、業界で通用しているストアドプロシージャーという名称を使用していますが、4D Server のストアドプロシージャーの機能は、通常のストアドプロシージャーの概念をはるかに超えています。

ローカルモードの4Dでのようなコマンドを使用すると、メソッドを実行できるユーザープロセスを開始することができます。このメソッドはプロセスメソッドと呼ばれています (4D Language Referenceマニュアルのプロジェクトメソッド参照)。

4D Server上でもクライアントマシンと同様の操作が可能です。さらにコマンドを使用すると、4D Serverマシン上でメソッドを実行できるユーザープロセスを開始できます。を使用すれば異なるクライアント上の他のプロセスでメソッドを実行できます。
両ケースでこのメソッドはストアドプロシージャーと呼ばれ、(用語の濫用になりますが) サーバーマシンやクライアント上で開始されたプロセスもストアドプロシージャーと呼ばれます。

重要: SQL ベースのストアドプロシージャーと4D Server のストアドプロシージャーの本質的な違いは、SQL ベースのストアドプロシージャーではSQL プロシージャーを実行し、4D Server のストアドプロシージャーではスタンドアロン4Dプロセスを実行するという点にあります。

通常のプロセスと同様に、ストアドプロシージャーには次のような独自の環境があります

• テーブルごとのカレントセレクション: 各ストアドプロシージャーには、個別のカレントセレクションがあります。1 つのテーブルは、別々のストアドプロシージャーで異なるカレントセレクションを持つことができます。
• テーブルごとのカレントレコード: 各テーブルは、ストアドプロシージャーごとに異なるカレントレコードを持つことができます。
• 変数: 各ストアドプロシージャには独自のプロセス変数があります。プロセス変数は、その変数が設定されたストアドプロシージャの範囲内でのみ認識されます。
• デフォルトテーブル: 各ストアドプロシージャーには、独自のデフォルトテーブルがあります。
• プロセスセット: 各ストアドプロシージャーには、独自のプロセスセットがあります。
• エラー処理: 各ストアドプロシージャーには、独自のエラー処理メソッドを持てます。
• デバッガウィンドウ: 各ストアドプロシージャーは、独自のデバッガーウィンドウを持てます。

ユーザーインターフェースの点では、ストアドプロシージャーは、ウィンドウを開き、データを表示する (例えばを使用) ことができます。
4Dクライアントマシン上で実行されるストアドプロシージャーではデータ入力ができます。
一方、サーバー上で実行されるストアドプロシージャーではデータ入力を開始する (例えばを使用) ことはできません。これは、サーバーマシン上にデータ入力カーネルがないためです。

ストアドプロシージャーは、システム (ハードウェアおよびメモリ) が許す限りいくつでも開始することができます。事実、4D Server マシンは、4DクライアントおよびWeb ブラウザーに応答するマシンであるだけではなく、サーバーマシンおよびリモート4Dマシン上で実行中の他のプロセスと対話するプロセスを実行するマシンである、という見方をする必要があります。

4Dがマシン上で実行されるユーザープロセスのマルチタスク環境を提供するのと同じ方法で、4D Serverはストアドプロシージャーに対してマルチタスク環境を提供します。たとえば、4D Server はプロセス間通信用にストアドプロシージャーで使用できるインタープロセス変数テーブルを管理しています。

注: "サーバー上で実行"メソッド属性を使用して、サーバー上のプロセスでメソッドを実行することもできます。ただしこの場合メソッドは、クライアントプロセスに対応するサーバー上のクライアントプロセスで実行されます。つまりクライアントプロセスの環境を使用できます。この場合、これは4Dのストアドプロシージャーではありません。詳細はサーバー上で実行属性を参照してください。

データ入力を除き、4D Language Referenceマニュアルで説明されている、ほとんどすべてのプロセスおよびコマンドの機能は、ストアドプロシージャーにも適用されます。

ストアドプロシージャーではレコードの追加、検索、並べ替え、更新、削除が可能です。ストアドプロシージャーではセットや命名セレクションの使用、ディスク上のドキュメントファイルへのアクセス、BLOB を使用した作業、レコードの印刷等が行えます。ローカルの4Dマシン上で作業を行う代わりに、サーバーマシン上や他の4Dクライアントマシン上で実行していると考えてください。

ストアドプロシージャーの明らかな利点は、データベースエンジンがあるサーバーマシン上でローカルに実行されるということです。例えば、ネットワーク経由でを行うと効率的ではありませんが、ストアドプロシージャー内では効率良く実行されます。SPベースの読み込み (例題)に示された例では、“スマート”なストアドプロシージャーを使用して、大幅なパフォーマンスの最適化を実現しています。

クライアントマシン上で実行されるストアドプロシージャーを使用すれば、タスクの分割やクライアントマシン間の通信を最適化できます。複数のマシンでストアドプロシージャーを実行する例題は、4D Language Reference内のを参照してください。

しかし、ストアドプロシージャアーキテクチャーの最も重要な利点は、4D Server に追加の世界をもたらすところです。ストアドプロシージャーを利用すると、独自の4D Serverサービスを実現することができます。これを制限するのは想像力だけです。SPベースのサービス (例題)の例では、4D Server またはサーバーマシンについての情報をクライアントに提供するストアドプロシージャーを示しています。例えば、サーバーマシンのボリュームを一覧表示することが可能です。この例は、ディレクトリ情報やドキュメント情報をクライアントに返すように簡単に拡張することができます。

一般的に言って、サーバー上で実行されるストアドプロシージャーはインターフェース (メニューやウィンドウ、フォームなど) を扱うべきではありません。実際インターフェースはサーバー上では管理されません。

サーバーマシン上でモーダルダイアログボックスを生成しうる可能性のあるコマンド(例: に第一引数に空の文字列を渡して呼び出すなど)は、全て避けるべきです。サーバー画面の前には必ずしも常にユーザーがいるわけではないため、ユーザーアクションが必要なモーダルなダイアログボックスを表示することは、アプリケーションの一時的なブロックにつながることがあるという点に注意してください。

以下はサーバー上で実行されるストアドプロシージャー内で使用すべきでないコマンドのリストです。

• サーバー上で禁止されるコマンド

以下のコマンドの１つををストアドプロシージャー内で使用したら、4D Server 上で使ってはいけないというアラートが表示されます。エラーは#67 が返ります。コマンドでインストールされたメソッドを通し、受け取ることができます。

• サーバー上で効果がないコマンド

以下のコマンドはサーバー上のストアドプロシージャーで呼び出された場合、効果がありません。特定のエラーコードは返されません。

• 4Dからメソッド実行ダイアログボックスを使用して、手動でストアドプロシージャーを開始できます:

ここからメソッドを4D Serverまたは他の4Dクライアントマシン上で実行できます。このリストに4Dクライアントマシンを表示させるためには、まずそのマシンが登録されていなければならないことに留意してください (クライアントマシン上でのストアドプロシージャとコマンドを参照)。

• また4D上で、またはコマンドを使用してプログラムからストアドプロシージャーを開始できます。.

注: リモート4Dからサーバのストアドプロシージャに、、そしてなどのプロセス管理コマンドを使用することはできません。

• 4D Server上で実行されているメソッド (サーバデータベースメソッド、サーバ上で実行属性付きのメソッド、またはストアドプロシージャ) は、、またはを使用してストアドプロシージャを開始できます。

ストアドプロシージャー間の通信には、次の方法を使用します:

• ストアドプロシージャーセッション のsession.storage 共有オブジェクト
• ローカルセマフォーまたはグローバルセマフォー
• レコード
• 、 および コマンド
• (非推奨) インタープロセス変数、インタープロセスセットおよびインタープロセス命名セレクション

4D Language Referenceマニュアルで、関連する箇所を参照してください。4Dコマンドは、クライアントマシンのスコープ内で動作する場合と同様に、ストアドプ ロシージャーを実行するサーバーまたはクライアントマシンのスコープ内で動作することに注意してください。

注: およびOutside call メカニズムは、サーバーマシン上では意味がありません。ストアドプロシージャーには、データ入力のためのユーザーインタフェースがないためです。

さらにもう1 つ重要な機能があります。クライアントユーザープロセス (クライアントマシンで実行されるプロセス) は、、、コマンドを使用して、ストアドプロシージャーのプロセス変数 (*) を読み込んだり、書き込むことができます

(*) サーバーマシンのインタープロセス変数も同様

重要: 、、コマンドを使用して行う“マシン間”のプロセス通信は、クライアントからサーバーに対してのみ可能です。ストアドプロシージャーの変数を読み込んだり、書き込んだりするのは常にクライアントのプロセスです。