メインコンテンツまでスキップ
バージョン: 開発中

クライアント/サーバー

組み込みクライアント/サーバーアプリケーションまたはリモートプロジェクトの形で、4Dデスクトップアプリケーションをクライアント/サーバー構成で運用することができます。

  • 組み込みクライアント/サーバーアプリケーション は アプリケーションビルダー を使って生成します。 これらは、アプリケーションの運用に使います。

  • リモートプロジェクト とは、4D Server 上で開いた .4DProject ファイルのことで、リモートモードの 4D を使って接続します。 4D Server は、プロジェクトの 圧縮形式 である .4dz ファイルをリモートの 4D に送信します。つまり、ストラクチャーファイルは読み取り専用です。 この構成は通常、アプリケーションのテストに使います。

ただし、4D Server と同じマシン から接続している場合には、プロジェクトファイルの変更が可能です。 この 特殊機能 により、クライアント/サーバーアプリケーションを運用時と同じコンテキストで開発することができます。

組み込みクライアント/サーバーアプリケーションを開く​

ビルドされたクライアント/サーバーアプリケーションは起動や接続処理が簡易です:

  • サーバーを起動するには、サーバーアプリケーションをダブルクリックします。 プロジェクトファイルを選択する必要はありません。
  • クライアントを起動するにも、同様にクライアントアプリケーションをダブルクリックします。すると、サーバーアプリケーションへの接続が直接おこなわれるため、

詳細については アプリケーションビルド ページを参照ください。

リモートプロジェクトを開く​

4D Server 上で動いているプロジェクトに初めて接続する場合は、通常は標準の接続ダイアログを使います。 以降は、最近使用したプロジェクトを開く メニューや、4DLink ショートカットファイルを使って直接接続できるようになります。

4D Server で実行されているプロジェクトに接続するには:

  1. 次のいずれかの方法をおこないます:
    • Welcome ウィザードにて 4D Serverに接続 を選択します。
    • ファイル メニューより **開く ＞ リモートプロジェクト...**を選択するか、開く ツールバーボタンより同様に選択します。

4D Server に接続するためのダイアログが表示されます。 ダイアログには 最近使用、利用可、および カスタム という、3つのタブがあります。

リモートの 4D と同じサブネットワークに 4D Server が接続されている場合は 利用可 タブを選択します。 4D Server には組み込みのブロードキャストシステムがあり、デフォルトで、ネットワーク上に利用可能な 4D Server データベースの名前を公開します。 このリストは、名前が見つかった順に表示され、動的に更新されます。

このリストからサーバーに接続するには、名前上でダブルクリックするか、名前を選択して OK ボタンをクリックします。

公開されているプロジェクトが 利用可 タブに見つからない場合には、カスタム タブを開きます。 カスタムページでは、IPアドレスでネットワーク上のサーバーを指定し、それに任意の名前をつけられます。

  • プロジェクト名: 4D Server プロジェクトのローカル名を指定できます。 この名前は 最近使用 ページでプロジェクトを参照する際に使用されます。
  • ネットワークアドレス: 4D Server が起動されたマシンの IPアドレスを指定します。
    • 2つのサーバーが同じマシン上で同時に起動されているときは、IPアドレスの後にコロンとポート番号を続けます。例: 192.168.92.104:19820。
    • デフォルトで、4D Server の公開ポートは 19813 です。 この番号は、プロジェクト設定で変更できます。

開発モードを有効化する オプションは、特別な読み取り/書き込みモードでリモート接続を開きます。このモードでは、リモート4D からプロジェクトフォルダーへのアクセスが確保されている必要があります。

このページでサーバーを指定したら、OK ボタンをクリックしてサーバーに接続できます。

サーバーとの接続が確立されると、そのリモートプロジェクトは 最近使用 タブのリストに加えられます。

サーバー上のプロジェクトファイルの更新​

インタープリターモードの場合、4D Server は .4DProject プロジェクトファイル (非圧縮) の .4dz ファイルを自動的に作成し、リモートマシンに送信します。

  • プロジェクトが編集され 4D Server にリロードされた場合など、必要に応じてプロジェクトの .4dzファイルは自動的に更新されます。 プロジェクトは次の場合にリロードされます:
    • 4D Server アプリケーションウィンドウが OS の最前面に来たり、同じマシン上の 4D アプリケーションが編集を保存した場合 (後述参照) に自動でリロードされます。
    • RELOAD PROJECT コマンドが実行されたとき。 プロジェクトの新しいバージョンをソース管理システムよりプルしたときなどに、このコマンドを呼び出す必要があります。

リモートマシンのプロジェクトファイルの更新​

4D Server 上で .4dz ファイルの更新版が生成された場合、その更新版を利用するには、接続中のリモート 4D マシンは一度ログアウトし、4D Server に再接続する必要があります。

開発モード​

4D Server における 開発モード とは、接続したリモート4D アプリケーションに読み/書きアクセスが許可されるプロジェクトを開くときの特別なモードです。 プロジェクトはインタープリター モード でなければなりません。

このモードでは、同じプロジェクトに対して複数のデベロッパーがデザイン環境で同時に作業することができます。 プロジェクトが開発モードで開かれている場合、以下のような特徴があります:

  • プロジェクトファイルは読み/書きが可能な状態なので、メソッドやフォームなどを編集することができます。
  • 複数のリモート4D が、同じインタープリター版のプロジェクトファイルを同時に開いて、それを編集することができます。 この場合、自動ロックシステムが同じリソースへの同時アクセスを防止します。
  • 編集は全てのリモートデベロッパーに対して利用可能になります。 ただし、このときリモートデベロッパーに対しては自動的なプッシュは起こらなず、最新のバージョンのファイルを取得するためには更新を行う必要があります(更新は、デベロッパーがデザインモードからアプリケーションモードへと切り替えるか、あるいは ファイル メニューから 全て保存 を選択したときに毎回起こります)。

このモードを使用するには、リモート4D から接続ダイアログボックス から開発モードを有効化する を選択する必要があります。 次に4D プロジェクトファイルを選択してくださいと表示されます: 4D Server が開いている .project ファイル を選択する必要があります。 異なるファイルを選択した場合、開発モードが利用できないことを警告するアラートダイアログボックスが表示されます。 これは、リモート4D がプロジェクトフォルダーに対してネットワーク越しでもアクセス権を持っていなければならないことを意味します(例えばプロジェクトのroot フォルダーが共有されているなど、プロジェクトファイル全体が共有されている必要があります)。

caution

この設定においてはパフォーマンス上の理由から、プロジェクトフォルダーがローカルネットワーク上の専用のファイルサーバー上(例: NAS など)に保存することが強く推奨されています。

注

サーバーとリモート4D が同じマシン上にある場合、追加のルールが適用されます。

開発モードアーキテクチャーの概要は以下のようになります:

互換性

この機能は、バイナリーデータベースで作業するのに慣れていて、現在の構成を維持したままプロジェクトモードでの機能を利用したいような、小規模な開発チーム向けに設計されています。 しかしながら、4D プロジェクト上でのマルチユーザー開発については、デベロッパーがそれぞれのマシン上で開発を行い、その作業をソース管理リポジトリツール(Git、SVN など)で管理する標準のアーキテクチャーを使用することが強く推奨されます。 この構成であれば、デベロッパーが異なるブランチで作業をしたり、行った編集の比較、マージ、差し戻しなどが可能になり、大きな柔軟性を持ちます。

関連したblog 記事

Developing Concurrently on 4D Server in Project Mode

4D と 4D Server の同じマシン上での使用​

同じマシン上で 4D が 4D Server に接続すると、アプリケーションはシングルユーザーモードの 4D のようにふるまい、デザイン環境にてプロジェクトファイルの編集が可能です。 この機能により、クライアント/サーバーアプリケーションを運用時と同じコンテキストで開発することができます。

同じマシン上で 4D Server に 4D を接続する場合には、 開発モード オプションの設定にかかわらず 開発モード が自動的に有効化されます。

デザイン環境にて 4D が すべてを保存 アクションを (ファイル メニューを使って明示的に、または、アプリケーションモードへの移行により暗示的に) おこなうと、4D Server は同期的にプロジェクトファイルをリロードします。 4D Server によるプロジェクトファイルのリロードが完了するのを待って、4D は続行します。

ただし、標準のプロジェクトアーキテクチャー とは次のふるまいにおいて異なりますので、注意が必要です:

  • 4D が使用する userPreferences.{username} フォルダーは、4D Server が使用するプロジェクトフォルダー内のものと同一ではありません。 この専用の "userPreferences" フォルダーはプロジェクトシステムフォルダー内 (つまり、.4dzプロジェクトを開く場合と同じ場所) に格納されます。
  • 4D が使用する DerivedData フォルダーは、4D Server が使用するプロジェクトフォルダー内のものと同一ではありません。 この専用の "DerivedDataRemote" フォルダーはプロジェクトのシステムフォルダー内に格納されます。
  • catalog.4DCatalog ファイルは 4D ではなく 4D Server によって編集されます。 catalog の情報はクライアント/サーバーリクエストによって同期されます。
  • directory.json ファイルは 4D ではなく 4D Server によって編集されます。 directory の情報はクライアント/サーバーリクエストによって同期されます。
  • 4D は、4D Server 上のものではなく、独自の内部的なコンポーネントやプラグインを使用します。

プラグインやコンポーネントを 4D あるいは 4D Server アプリケーションレベルにインストールすることは、推奨されません。

クライアント/サーバー開発​

コードの実行場所​

クライアント/サーバーアプリケーションにおいては、コードが実際に実行される場所を知っておくことが重要です: サーバー側 あるいは クライアント側 のどちらかです。 実行場所を知っておくことは、ユーザーセッション関連のコードの実装、プロセス間での情報の共有、またはデータのアクセスなどの際に非常に重要となります。

以下の表は、デフォルトでのコードの実行場所と、その実行場所を切り替えるための方法(許可されていれば)をまとめたものです。 この表での ローカル とは、コードはそれが実際に呼ばれたマシン上で実行されることを意味するという点に注意してください。

コードデフォルトの実行場所切り替え方法
ORDA データモデル関数server関数定義内で local キーワードを使用
ORDA 計算属性関数のうち get()、 set()server関数定義内で local キーワードを使用
ORDA 計算属性関数のうち query()、 orderBy()servern/a
ORDA イベント関数 (全般)servern/a
ORDA イベント関数 constructor()localn/a
ORDA イベント関数 event touched()server関数定義内で local キーワードを使用
ユーザークラス関数localn/a
共有シングルトンまたは施ッションシングルトンの関数local関数定義内で server キーワードを使用
トリガーservern/a
クライアントから呼び出されたプロジェクトメソッドclientサーバー上で実行する オプション をチェックする。 コードは、ユーザーセッションプロセス のツインプロセス内で実行されます。
Execute on server コマンドを呼び出す。 コードはストアドプロシージャーセッション 内で実行されます。
サーバー上のストアドプロシージャー から呼び出されたプロジェクトメソッドserverEXECUTE ON CLIENT コマンドを呼び出す。 ターゲットとなるクライアントは 登録されている 必要があります。
オブジェクトメソッドlocaln/a
データベースメソッド:servern/a
データベースメソッド:clientn/a

トリガー​

トリガー はデータベースエンジンが実際に存在するマシン上で実行されます。 4D Server では、トリガーはサーバーマシン上で実行されるプロセスのコンテキスト内で実行され、クライアントマシン上では実行されません。 具体的には、データベース操作を呼び出すユーザープロセスの "ツイン" プロセスのコンテキスト内で実行されます。 これらのツインプロセスはクライアント上のユーザープロセスと同じデータベースコンテキスト (具体的にはトランザクションの状態とレコードのロッキング) を共有しますが、ランゲージコンテキスト (変数、プロセス、セット、カレントセレクションなど) は共有しません。 ただしトリガーのテーブルのカレントレコードはすべてのコンテキストにおいて同じであるという点に注意してください。

注

サーバー上では、トリガーは割り当てられたアクション (作成/更新/削除) を処理するプロセス内で実行されます。 アクションがサーバー上のプリエンプティブプロセス (例: ストアドプロシージャーやスケーラブルセッションモードでの HTTPリクエスト) でトリガーされた場合には、トリガーは同じプリエンプティブプロセス内で実行されます。 ただし、アクションが 4Dリモートからトリガーされていた場合、トリガーはツインプロセスで実行され、このツインプロセスは必ずコオペラティブモードで実行されます (ツインプロセスはユーザーのすべての呼び出しに対して共有されます)。

ストアドプロシージャー​

4D のストアドプロシージャーとは、メソッドを実行したクライアントマシンではなく、サーバーマシン (あるいは登録されたクライアントマシン) 上で実行中のプロセス内でプロセスメソッドを実行するプロジェクトメソッドです。

ローカルモードの 4D では、New process などのコマンドを使用すると、メソッドを実行できるユーザープロセスを開始することができます。 このメソッドはプロセスメソッド と呼ばれています。 同じことは、4D Server、クライアントマシンで行うことができます。 また、サーバーマシン上でExecute on server コマンドを使用することで、メソッドを実行できるユーザープロセスを開始することができます。 さらに、EXECUTE ON CLIENT コマンドを使用すると異なるクライアント上の他のプロセス内でメソッドを実行することができます。 どちらの場合においても、このメソッドはストアドプロシージャーと呼ばれ、またサーバーマシンまたは他のクライアント上で開始されたプロセスについても(比喩から)同じくストアドプロシージャーと呼ばれます。

注

サーバー上で実行されるすべてのストアドプロシージャーは同じ仮想的なユーザーセッションを共有します。

アーキテクチャー​

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

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

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

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

注

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

ストアドプロシージャーの機能​

サーバー上で実行されるストアドプロシージャーでのデータ入力を除き、ほとんどすべてのプロセスおよび4D ランゲージの機能は、ストアドプロシージャーにも適用されます。

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

ローカルに実行されるストアドプロシージャーに対しサーバー上で実行されるストアドプロシージャーの明確な利点とは、データベースエンジンがあるサーバーマシン上でローカルに実行されるということです。 例えば、ネットワーク経由でAPPLY TO SELECTION を行うと効率的ではありませんが、ストアドプロシージャー内では効率良く実行されます。

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

しかし、ストアドプロシージャーアーキテクチャーの最も重要な利点は、4D Server に追加の世界をもたらすところです。 ストアドプロシージャーを利用すると、独自の4D Server サービスを実現することができます。 唯一の制約はあなたの想像力だけです。

ストアドプロシージャーが行わないこと​

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

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

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

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

ADD RECORD APPEND MENU ITEM POST OUTSIDE CALL CHANGE LICENSES Count menu items Count menus DELETE MENU ITEM DISABLE MENU ITEM DISPLAY SELECTION EDIT ACCESS ENABLE MENU ITEM FILTER EVENT Get menu item Get menu item key Get menu item mark Get menu item style Get menu title SET PICTURE TO LIBRARY INSERT MENU ITEM Menu selected MODIFY RECORD MODIFY SELECTION ON EVENT CALL QUERY BY EXAMPLE QR REPORT REMOVE PICTURE FROM LIBRARY SET MENU ITEM SET MENU ITEM SHORTCUT SET MENU ITEM MARK SET MENU ITEM STYLE SET PICTURE TO LIBRARY SET USER ALIAS SHOW MENU BAR

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

GRAPH MESSAGES OFF MESSAGES ON SET MENU BAR SHOW TOOL BAR

ストアドプロシージャーを開始する​

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

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

  • また 4D 上では、Execute on server または EXECUTE ON CLIENT コマンドを使用してプログラムからストアドプロシージャーを開始できます。
  • 4D Server上で実行されているメソッド (サーバーデータベースメソッド、サーバー上で実行属性付きのメソッド、またはストアドプロシージャー) はExecute on server、 New process、または EXECUTE ON CLIENT を使用してストアドプロシージャーを開始できます。
注

リモート4D からサーバーのストアドプロシージャーに、DELAY PROCESS, PAUSE PROCESS および RESUME PROCESS などのプロセス管理コマンドを使用することはできません。

ストアドプロシージャーとユーザープロセス間のインタープロセス通信について​

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

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

注

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

クライアントユーザープロセス (クライアントマシンで実行されるプロセス) は、GET PROCESS VARIABLE、 SET PROCESS VARIABLE および VARIABLE TO VARIABLE コマンドを使用して、ストアドプロシージャーのプロセス変数 (*) を読み込んだり、書き込むことができます。

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

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

クライアントマシン上でのストアドプロシージャー​

ストアドプロシージャーを 1つあるいは複数の 4Dマシン上で実行できます。 クライアント上のストアドプロシージャーは、サーバー上のそれとおなじように実行されますが、クライアント上ではADD RECORD などの従来のコマンドを使用してデータ入力を行うことができます。

サーバーまたは他のクライアントマシンによって起こされた、どのようなクライアントマシンで実行されているストアドプロシージャーも、明示的にこのセッションに登録されなければなりません。 4D クライアントを登録するには2つの方法があります。接続時に自動登録またはプログラミングによる登録です。

  • 4D Server へ接続する各 4Dクライアントマシンを自動的に登録する: データベース設定のクライアント-サーバーページ中、公開オプションタブのExecute On Client のために起動時にクライアント登録チェックボックスを利用します。 このオプションにチェックを入れると、データベースに接続した各 4Dクライアントマシンは、ストアドプロシージャーを実行することができるクライアントとして、4D Server から自動的に参照されます。 クライアントマシンに応じて名前がつけられた 4Dクライアントタイプのプロセスは、サーバー上に作成されます。 また対応するプロセスが、各クライアントマシン上に作成されます。
  • プログラミングによる 4Dクライアントの登録: プログラミングを使って 1つまたは複数の 4Dクライアントマシンを登録することができます。この方法では登録に必要なクライアントマシンを選択し、登録名を決めることができます。 REGISTER CLIENT コマンドで、どのような名前でもクライアントマシンを登録することができます。
  • 4D クライアントの登録解除: クライアントマシンが登録された方法にかかわらず、UNREGISTER CLIENT コマンドで現在のセッションから指定したクライアントを登録解除することができます。 クライアントごとに付けられた名前の登録プロセスはサーバーマシンのユーザープロセスグループから消え、クライアント上の対応するプロセスも終了されます。

GET REGISTERED CLIENTS コマンドを使用して、セッションに登録されたクライアントのリストとタスク割り当て(実行待ちのメソッド数)を取得することができます。

変数​

すべてのプロセス同様、各ストアドプロシージャーには独自のプロセス変数があります。 これらのプロセス変数、実行の各フェーズにおいて作成して動的に使用することができます。

4D Server はインタープロセス変数 のテーブルを一つ管理しています(インタープロセス変数は 非推奨です)。 これらの変数のスコープはサーバーマシンです。 コンパイルしたデータベースを実行している場合、インタープロセス変数テーブルの定義は、サーバーマシンとすべてのクライアントマシンとで共通です。各マシンはそれぞれ独自のインスタンスを保持します。

セットと命名セレクション​

  • プロセスセット/命名セレクション: プロセスオブジェクトには、それを作成したプロセス内、およびクライアントプロセスで作成された場合には対応するサーバー上のクライアントプロセス上でのみアクセスできます。 プロセスセットは、プロセスメソッドが終了すると直ちに消去されます。 プロセスオブジェクトはその名前に特別な接頭辞を必要としません。
  • インタープロセスセット/命名セレクション(非推奨): インタープロセスオブジェクトはそれが作成されたマシン上 (クライアントまたはサーバー) のすべてのプロセスで可視です。 名前の前に"小なり記号"と"大なり記号"の組合せ (<>) が付いていれば、そのセットや命名セレクションはインタープロセスセットです。
  • ローカル/クライアントセット/命名セレクション: ローカル/クライアントオブジェクトはそれが作成されたプロセス内でのみ可視です。 ローカル/クライアントオブジェクトの名前の前には、ドル記号 ($) を付けます。 注: UserSet システムセットの名前は$ で始まっていませんが、ローカル/クライアントセットです。

以下の表は命名セレクションとセットがどこで作成されたかに基づき、これらの可視性の原則を示しています (表は両タイプのオブジェクトで共通です):

クライアントプロセス他のクライアントプロセスサーバープロセス他のサーバープロセス
クライアントプロセス内で作成された
$test○
test○○ (トリガー)
<>test○○
サーバープロセス内で作成された
$test○
test○
<>test○○

x = 可視

行いたい処理に基づき、この可視表を常に心にとめておいてください。 例えばDIFFERENCE、 INTERSECTION あるいはUNION タイプの処理を行うとき、すべてのセットや命名セレクションが、処理を行うマシン上で可視であることを確認してください。

サーバー上で実行属性​

The サーバー上で実行 プロジェクトメソッド属性は属性の一括設定ダイアログやメソッドプロパティダイアログ を使用して設定できます。 このオプションが選択されていると、そのプロジェクトメソッドは呼び出し方に関わらず常にサーバー上で実行されます。

実行コンテキスト​

この属性が選択されている場合、そのプロジェクトメソッドの実行コンテキストはトリガーのそれと同じものになります。つまり、サーバー上で実行されるメソッドは、レコードロックやトランザクションについてクライアント側の対応する同じデータベースコンテキストを共有しますが、ランゲージコンテキスト (プロセス変数、セット、カレントセレクション) は共有しません。 しかしながらトリガーと異なり、サーバー上で実行されるメソッドはクライアントコンテキストのカレントレコードを共有しない点に留意してください (トリガーはトリガーテーブルのカレントレコードを共有します)。 メソッドのすべての引数 はサーバーに送信され、戻り値が (使用されていれば) クライアントに返されます。

Execute on server コマンドと異なり、このオプションはサーバー上にプロセスを作成しません。 4D Server は、実行をリクエストしたクライアントプロセス("ツイン"プロセス)に対応するサーバー側のクライアントプロセスを使用します。 さらにこのオプションは、"普通"のメソッド呼び出しのように、引数の交換が両方向で自動化されるので、サーバーにメソッドの実行を移譲することが簡単になります。 Execute on server コマンドの場合、これは非同期で動作するため、追加のプログラミングと、結果を読み込むためのセマフォー が必要です。

使用できるコマンド​

"サーバー上で実行"属性を持つメソッドは、4Dランゲージコマンドの利用においては、ストアドプロシージャー と同じルールが適用されます。

ポインター​

変数へのポインター (変数、配列、または配列要素) を渡した場合、参照先の値もサーバーに送信されます。 サーバー上でメソッドにより参照先の値が更新されると、更新された値がクライアントに返され、クライアント側の対応する変数が更新されます。 テーブルやフィールドのポインターは参照として送られます (テーブル番号、フィールド番号)。 カレントのレコード値は自動では交換されません。

注

このオプションはインタープリターモードとコンパイルモード で同じように動作します。

例題​

以下は"サーバー上で実行"属性が設定されたMyAppli プロジェクトメソッドのコードです:

 #DECLARE($table: Pointer; $field: Pointer; $array: Pointer; $search: Text) -> $result : Integer
 
  //検索を行いレコード毎の結果を返す
 QUERY($table->;$field->=$search)
 While(Not(End selection($table->)))
    APPEND TO ARRAY($array->;myFormula($table))
    NEXT RECORD($table->)
 End while
 UNLOAD RECORD($table->)
 $result:=Records in selection($table->)

クライアント側で、メソッドは以下のように呼び出されます:

 ARRAY TEXT(myArray;0)
 var $vlnum:=MyAppli(->[Table_1] ;->[Table_1]Field_1 ;->myArray;"to find")

Resources フォルダー​

データベースの Resources フォルダー を使用して、カスタムデータ (ピクチャー、ファイル、サブフォルダー等) を サーバーマシンとすべてのクライアントマシンで共有できます。 Resources フォルダーはサーバーマシン上で プロジェクトルートフォルダー の第一階層になければなりません。

Resources フォルダーに関連付けられたすべての参照メカニズムは、クライアント/サーバーモードでもサポートされています (.lprojフォルダー、XLIFF、ピクチャーなど)。

クライアントはそれぞれこのフォルダーのローカルコピーを持ちます。 ローカルフォルダーの内容は、クライアントがサーバーに接続するたびに自動でサーバーのそれと同期されます。

さらに、サーバーデータベース上の Resources フォルダーの内容が開発者によりセッション中に更新されたとき、クライアントマシンはその通知を受け取ることもできます。 この通知は以下をトリガーとして行われます:

  • クライアントから最新の更新が行われてから2分後、サーバーが自動で行う (この遅延は多数のファイルがコピーされた場合の不適切な通知を避けるためのものです)。
  • または更新を行ったクライアントマシン上のリソースエクスプローラー のアクションメニューから[クライアントに通知コマンド]を選択する。
  • またはNOTIFY RESOURCES FOLDER MODIFICATION コマンドを使用してプログラミングで行う。 このコマンドは Resources フォルダーの内容がストアドプロシージャーを使用してサーバー上で更新された場合に便利です。

クライアント側では、環境設定のセッション中に"Resources"フォルダーを更新 の設定に基づき、この通知に対する処理が決定されます。 この設定はSET DATABASE PARAMETER コマンドのAuto synchro resources folder セレクター を使用して、個々に設定することもできます。 3つの選択肢があります: 同期しない、 自動で同期する そして その都度指定。 詳細はネットワーク/クライアント-サーバー通信 ネットワーク/クライアント-サーバー通信 の節 を参照してください。

最後に、それぞれのクライアントマシンはいつでもリソースエクスプローラー のアクションメニューのローカルリソースを更新コマンドを使用してサーバーと同期できます。