注意: 9.1 組み込み関数の規則 &<a href="bifcat3_01.htm"&>利用オプション&</a&>
指定された物理ファイル(およびそれに基づくビュー)に対する後続の全I/O要求をサーバーに再経路指定するようにLANSAを準備します。詳細については、「&<a href="database_connection_note.htm"&>データベースの接続&</a&>」を参照してください。
ファイル接続の確立は非常に高速で、時間はほとんどかかりません。経路指定テーブルを更新するだけで、サーバーとの通信はまったく行われません。
この接続は、組み込み関数DISCONNECT_FILEを使用するか、LANSA環境を終了させるなどの明らかな停止処理が取られるまで有効です。
アプリケーションを設計する際は、接続および切断ポイントを最小限にするような設計にすべきです。
複数のファイルを複数のサーバー・システムに同時に接続することは可能ですが、1つのファイルを複数のサーバーに同時に接続することはできません。
ここで言及する「ファイル」とは、基本となる物理ファイル(またはテーブル)とそれに基づくすべての論理ファイル(またはビュー)を指します。
すでに接続されているファイルに対する接続要求があると、選択ブロック・サイズと選択制限がリセットされることを除き、無視されます。エラーにはなりません。
以下の場合に接続要求を出すと、致命的なエラーが発生します。
引数
番号 |
タイプ |
必須/任意 |
記述 |
最小長 |
最大長 |
最小小数桁数 |
最大小数桁数 |
1 |
A |
必須 |
物理ファイル\テーブル名 |
1 |
10 |
|
|
2 |
A |
必須 |
定義されているサーバーのSSN |
1 |
10 |
|
|
3 |
N |
任意 |
選択CONNECT_FILE ブロック・サイズの使用。デフォルト = 50 |
1 |
10 |
0 |
0 |
4 |
N |
任意 |
選択制限値。このオプションは、プログラムで選択ループを'n'行に制限するものではありません。この目的に使用しないでください。 |
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であっても、社員情報の保守はキーを指定して更新する必要があります。最後に読み取られたレコードを更新すると、このレコードは上書きされます。