4D v16ストアドプロシージャ |
||
|
4D v16
ストアドプロシージャ
ストアドプロシージャ
ストアドプロシージャーという表現は、SQLベースのサーバーの世界に由来しています。クライアントワークステーションがSQLベースのサーバーに要求を送信する時、実際にはSQLサーバーに対してSQL言語で記述されたテキストを送信します。この要求は、実行される前にSQLサーバー上で解釈されます。要求のソースコードのサイズが大きく、1回のセッション中に要求が何度も送信される場合には、送られる要求の回数が多いほど、ネットワーク経由でソースコードを送信、解析し、解釈する時間が長くなることは明らかです。 そこでネットワーク経由で要求を送信し、解析および解釈を一度だけ行い、クライアントワークステーションから受信するたびにこれを実行する方法を探しました。この解決方法は、要求のソースコード (つまりプロシージャー) をサーバー側に保存し、クライアントワークステーションには実行するプロシージャーの名前だけで構成される要求を送らせることでした。結果的に、このプロシージャーはサーバー上にストアされるため、"ストアドプロシージャー"という用語になっています。 SQLベースのストアドプロシージャーは、クライアントワークステーションから引数を受信し、実現するタスクを (同期的または非同期的に) 実行し、最終的に結果をクライアントワークステーションに戻すことができるプロシージャーであるということに注意してください。クライアントワークステーションがストアドプロシージャーの実行を開始すると、ある程度サーバーマシンにコードの実行を任せます。 4D Server では、業界で通用しているストアドプロシージャーという名称を使用していますが、4D Server のストアドプロシージャーの機能は、通常のストアドプロシージャーの概念をはるかに超えています。 ローカルモードの4DでNew processのようなコマンドを使用すると、メソッドを実行できるユーザープロセスを開始することができます。このメソッドはプロセスメソッドと呼ばれています (4D Language Referenceマニュアルのプロジェクトメソッド参照)。 4D Server上でもクライアントマシンと同様の操作が可能です。さらにExecute on serverコマンドを使用すると、4D Serverマシン上でメソッドを実行できるユーザープロセスを開始できます。EXECUTE ON CLIENTを使用すれば異なるクライアント上の他のプロセスでメソッドを実行できます。 重要: SQL ベースのストアドプロシージャーと4D Server のストアドプロシージャーの本質的な違いは、SQL ベースのストアドプロシージャーではSQL プロシージャーを実行し、4D Server のストアドプロシージャーではスタンドアロン4Dプロセスを実行するという点にあります。 通常のプロセスと同様に、ストアドプロシージャーには次のような独自の環境があります
ユーザーインターフェースの点では、ストアドプロシージャーは、ウィンドウを開き、データを表示する (例えばDISPLAY RECORDを使用) ことができます。 ストアドプロシージャーは、システム (ハードウェアおよびメモリ) が許す限りいくつでも開始することができます。事実、4D Server マシンは、4DクライアントおよびWeb ブラウザーに応答するマシンであるだけではなく、サーバーマシンおよびリモート4Dマシン上で実行中の他のプロセスと対話するプロセスを実行するマシンである、という見方をする必要があります。 4Dがマシン上で実行されるユーザープロセスのマルチタスク環境を提供するのと同じ方法で、4D Serverはストアドプロシージャーに対してマルチタスク環境を提供します。たとえば、4D Server はプロセス間通信用にストアドプロシージャーで使用できるインタープロセス変数テーブルを管理しています。 注: "サーバー上で実行"メソッド属性を使用して、サーバー上のプロセスでメソッドを実行することもできます。ただしこの場合メソッドは、クライアントプロセスに対応するサーバー上のクライアントプロセスで実行されます。つまりクライアントプロセスの環境を使用できます。この場合、これは4Dのストアドプロシージャーではありません。詳細はサーバー上で実行属性を参照してください。 データ入力を除き、4D Language Referenceマニュアルで説明されている、ほとんどすべてのプロセスおよびコマンドの機能は、ストアドプロシージャーにも適用されます。 ストアドプロシージャーではレコードの追加、検索、並べ替え、更新、削除が可能です。ストアドプロシージャーではセットや命名セレクションの使用、ディスク上のドキュメントファイルへのアクセス、BLOB を使用した作業、レコードの印刷等が行えます。ローカルの4Dマシン上で作業を行う代わりに、サーバーマシン上や他の4Dクライアントマシン上で実行していると考えてください。 ストアドプロシージャーの明らかな利点は、データベースエンジンがあるサーバーマシン上でローカルに実行されるということです。例えば、ネットワーク経由でAPPLY TO SELECTIONを行うと効率的ではありませんが、ストアドプロシージャー内では効率良く実行されます。SPベースの読み込み (例題)に示された例では、“スマート”なストアドプロシージャーを使用して、大幅なパフォーマンスの最適化を実現しています。 クライアントマシン上で実行されるストアドプロシージャーを使用すれば、タスクの分割やクライアントマシン間の通信を最適化できます。複数のマシンでストアドプロシージャーを実行する例題は、4D Language Reference内のREGISTER CLIENTを参照してください。 しかし、ストアドプロシージャアーキテクチャーの最も重要な利点は、4D Server に追加の世界をもたらすところです。ストアドプロシージャーを利用すると、独自の4D Serverサービスを実現することができます。これを制限するのは想像力だけです。SPベースのサービス (例題)の例では、4D Server またはサーバーマシンについての情報をクライアントに提供するストアドプロシージャーを示しています。例えば、サーバーマシンのボリュームを一覧表示することが可能です。この例は、ディレクトリ情報やドキュメント情報をクライアントに返すように簡単に拡張することができます。 一般に言って、サーバー上で実行されるストアドプロシージャーはインターフェース (メニューやウィンドウ、フォームなど) を扱うべきではありません。実際インターフェースはサーバー上では管理されません。 以下はサーバー上で実行されるストアドプロシージャー内で使用すべきでないコマンドのリストです。コマンドは3つにグループ化されます:
ACCUMULATE
ACCEPT (1) 第一引数が空の文字列の場合のみ
ここからメソッドを4D Serverまたは他の4Dクライアントマシン上で実行できます。このリストに4Dクライアントマシンを表示させるためには、まずそのマシンが登録されていなければならないことに留意してください (クライアントマシン上でのストアドプロシージャとREGISTER CLIENTコマンドを参照)。
注: リモート4Dからサーバのストアドプロシージャに、DELAY PROCESS、PAUSE PROCESSそしてRESUME PROCESSなどのプロセス管理コマンドを使用することはできません。
ストアドプロシージャー間の通信には、次の方法を使用します:
4D Language Referenceマニュアルで、関連する箇所を参照してください。4Dコマンドは、クライアントマシンのスコープ内で動作する場合と同様に、ストアドプ ロシージャーを実行するサーバーまたはクライアントマシンのスコープ内で動作することに注意してください。 注: CALL PROCESSおよびOutside callメカニズムは、サーバーマシン上では意味がありません。ストアドプロシージャーには、データ入力のためのユーザーインタフェースがないためです。 さらにもう1 つ重要な機能があります。クライアントユーザープロセス (クライアントマシンで実行されるプロセス) は、GET PROCESS VARIABLE、SET PROCESS VARIABLE、VARIABLE TO VARIABLEコマンドを使用して、ストアドプロシージャーのプロセス変数 (*) を読み込んだり、書き込むことができます (*) サーバーマシンのインタープロセス変数も同様 重要: GET PROCESS VARIABLE、SET PROCESS VARIABLE、VARIABLE TO VARIABLEコマンドを使用して行う“マシン間”のプロセス通信は、クライアントからサーバーに対してのみ可能です。ストアドプロシージャーの変数を読み込んだり、書き込んだりするのは常にクライアントのプロセスです。
参照
|
プロパティ
プロダクト: 4D
履歴
ARTICLE USAGE
4D Server ( 4D v16) |