現在地: LANSA テクニカル リファレンスガイド > 9. 組み込み関数 > 9.26 CONNECT_FILE

9.26 CONNECT_FILE

注意: 9.1 組み込み関数の規則      利用オプション

指定された物理ファイル(およびそれに基づくビュー)に対する後続の全I/O要求をサーバーに再経路指定するようにLANSAを準備します。詳細については、「データベースの接続」を参照してください。

ファイル接続の確立は非常に高速で、時間はほとんどかかりません。経路指定テーブルを更新するだけで、サーバーとの通信はまったく行われません。

この接続は、組み込み関数DISCONNECT_FILEを使用するか、LANSA環境を終了させるなどの明らかな停止処理が取られるまで有効です。

アプリケーションを設計する際は、接続および切断ポイントを最小限にするような設計にすべきです。

複数のファイルを複数のサーバー・システムに同時に接続することは可能ですが、1つのファイルを複数のサーバーに同時に接続することはできません。

ここで言及する「ファイル」とは、基本となる物理ファイル(またはテーブル)とそれに基づくすべての論理ファイル(またはビュー)を指します。

すでに接続されているファイルに対する接続要求があると、選択ブロック・サイズと選択制限がリセットされることを除き、無視されます。エラーにはなりません。

以下の場合に接続要求を出すと、致命的なエラーが発生します。

 

引数

番号

タイプ

必須/任意

記述

最小長

最大長

最小小数桁数

最大小数桁数

1

A

必須

物理ファイル\テーブル名

この名前は大文字で指定する必要があります。

指定された名前に対する妥当性検査や、この名前が存在するかどうかの確認は行われません。

名前は総称名で指定することが可能です。総称名の区切り文字としては、'*'を使用してください。

1

10

 

 

2

A

必須

定義されているサーバーのSSN

1

10

 

 

3

N

任意

選択CONNECT_FILE ブロック・サイズの使用。デフォルト = 50

注1：RETURN_RRNパラメータと一緒にSELECTループで使用されるファイルに対しては、ブロック・サイズ1を使用する必要があります。

これより大きいブロック・サイズを使用すると、RETURN_RRNの戻り値が予期できない値になります。

注2：SELECTループで使用され、WITH_KEYまたはWITH_RRNパラメータを持たないDELETEコマンドまたはUPDATEコマンド(最新の読み込んだレコードの更新または削除)によって変更されるファイルに対しては、ブロック・サイズ1を使用する必要があります。

注3：選択するフィールドのいずれかがBLOBまたはCLOBで、このためサーバーからクライアントにファイルを送信する必要がある場合、SELECTプロセスにブロック・サイズ1を使用したかのような振る舞いになります。

1

10

0

0

4

N

任意

選択制限値。このオプションは、プログラムで選択ループを'n'行に制限するものではありません。この目的に使用しないでください。

暴走した(すなわち、制御不能の)SELECTループによる大量データの転送を阻止するよう設計されています。

選択制限値を超えると、致命的なアプリケーション・エラーが発生します。このエラー状況で返される行数は未確定です。

デフォルト = 10000

1

10

0

0

 

 

戻り値

戻り値はありません。

技術上の注記

エラー処理に関する注意事項

複雑なエラー処理スキームをご使用のアプリケーションに組み込むことは避けるよう、強くお勧めします。アプリケーションのすべてのレベルで、以下のようなごく単純なトラップを使用するようにしてください。

if (#retcode *ne OK) 

    abort msgtxt('Failed to .............................')

endif

 

標準的なエラー処理を行う組み込み関数を生成されるアプリケーションに組み入れて、問題に対処するようにしてください。ユーザー定義のエラー処理ロジックが非常に複雑になったために全RDMLコードの40から50%を占有するようなケースもあります(アプリケーションには何のメリットもありません)。このような事態に陥らないようにしてください。

CONNECT_FILE ブロック・サイズの使用

ブロック・サイズのパラメータのデフォルトの値は50です。これは、サーバーと接続するたび、アプリケーションの最後に50個ずつレコードがクライアント側に戻されるという意味です。データは、特定のファイルに存在する順序で処理され、デバッグによって50のレコードをループするコードが示されますが、サーバーからデータを取得する接続は1回しか行われません。

このため、相対レコード番号または最後に読み取られたレコードを使用することには危険が伴います。

以下のコードで考えてみましょう。

SELECT FIELDS(...) FROM_FILE(FILEA) RETURN_RRN(#RRN)

...

UPDATE FIELDS(...) IN_FILE(FILEA) WITH_RRN(#RRN)

ENDSELECT

 

これは、IBM iサーバーでは許容されているコードです。しかし、クライアント/サーバー環境では、選択後のRRN値は、50番目のレコードの相対レコード番号になります。サーバー上のOAMは読み取りを1回実行しているため、これが最新のRRNとして認識されて戻されます。

同じことが次のコードにも当てはまります。

SELECT FIELDS(...) FROM_FILE(FILEA) RETURN_RRN(#RRN)

...

UPDATE FIELDS(...) IN_FILE(FILEA)

ENDSELECT

 

OAMに関する限り、最新のレコードは50番目のレコードになります。試行されるすべてのUPDATEまたはDELETEは、読み取られたこの最新レコードに対して実行されます。

SELECTループで使用されるファイルに対するキーの更新は許可されていません。このため、ブロック・サイズを1に設定することがこの場合の唯一の解決法です。こうすると、データには1回に1つずつレコードが戻されるようになります。

この方法のマイナス面は、アプリケーションのパフォーマンスが著しく低下することです。現時点では、サーバー上の複数のレコードを更新する最も効率的な方法は、CALL_SERVER_FUNCTION組み込み関数を使用してサーバー上で更新コードを実行する方法であることに注意する必要があります。

複数の詳細レコードをオープンできるようにアプリケーションを保守する場合にも、同様の問題が発生します。例えば、Visual LANSAアプリケーションで社員のリストを表示する場合があります。ユーザーがリスト内のある項目をダブル・クリックすると、その保守フォームをオープンすることができます。このリストから社員番号を受け取り、FETCHを使用してデータを読み取ります。FETCHによってOAMはレコードを1つだけ読み取ります。変更を保存する前に、ユーザーは別の社員の詳細情報も同様にオープンします。最後に読み取られた値がサーバー上のOAMに格納され、OAMが関係する間は、この値が2番目の社員情報となります。

したがって、実行されたのがFETCHであっても、社員情報の保守はキーを指定して更新する必要があります。最後に読み取られたレコードを更新すると、このレコードは上書きされます。