7.125.1 UPDATE のパラメータ

FIELDS

ファイル内の更新するフィールド、または更新するフィールドを指定するグループの名前を指定します。

拡張可能なグループ式を指定することもできます。詳細については、「フィールド・グループおよび拡張可能なグループ」を参照してください。以下の特別な値を指定できます。

*ALLを指定した場合、現在アクティブなファイルのすべてのフィールドが更新されます。
*ALL_REALを指定した場合、現在アクティブなファイルのすべての実フィールドが更新されます。
*ALL_VIRTを指定した場合、現在アクティブなファイルのすべての仮想フィールドが更新されます。
*EXCLUDINGを指定した場合、この特別な値に続けて指定するフィールドがフィールド・リストから除外されます。
*INCLUDINGを指定した場合、この特別な値に続けて指定するフィールドがフィールド・リストに含められます。この特殊な値は、*EXCLUDINGエントリーによって、フィールド・リストが除外モードに移行した後にのみ必要です。

注：OTHERによって保守されている論理ファイルからすべてのフィールドを更新すると、基になっている物理ファイルのすべてのフィールドがフィールド・リストに含められます。

パラメータFIELDSでは、特別な値*ALL、*ALL_REAL、または*ALL_VIRTを必要な場合にのみ慎重に使用することを強くお勧めします。必要のないフィールドを更新すると、クロスリファレンスの詳細(ファンクション内で使用されていないフィールドを示す)が無効になり、ファンクションのCRUDE項目の複雑度が無意味に高くなります。

移植性に関する考慮事項

IBM iで、コミット制御下にないファイルの1つ以上のLOBフィールドを更新する場合にI/Oエラーが発生すると、LOB以外のフィールドが更新され、1つ以上のLOBフィールドが更新されない可能性があります。

『LANSAアプリケーション設計ガイド』の「コミット制御」も参照してください。

IN_FILE

「I/Oコマンドでのファイル名の指定」を参照してください。

WITH_KEY

「I/Oコマンドでのファイル・キー・リストの指定」を参照してください。

このパラメータによる自動「相互更新」検査への影響の詳細については、次のコメント/警告のセクションを参照してください。

IO_STATUS

I/O操作の結果の「戻りコード」を受け取るフィールドの名前を指定します。

デフォルト値*STATUSを指定すると、戻りコードは、#IO$STSという特別なフィールドに保管されます。このフィールドは、他のフィールドと同様にRDMLプログラムで参照できます。

戻りコードを受け取るフィールドとしてユーザー・フィールドを指定する場合、このフィールドは、長さ2文字の英数字フィールドである必要があります。ユーザー・フィールドを指定した場合も、特別なフィールド#IO$STSは更新されます。

I/O操作の戻りコードについては、「I/Oコマンド戻りコード表」を参照してください。

IO_ERROR

コマンドの実行時にI/Oエラーが発生した場合に実行するアクションを指定します。

I/Oエラーは、「致命的」エラーと見なされます。ファイルが見つからなかった、ファイルが壊れている、ファイルを割り当てることができない、などがこれに該当します。これらのタイプのエラーが発生すると、ファンクションにおいて、そのファイルが関与しているすべての処理が停止します。

デフォルト値*ABORTを指定すると、ファンクションが異常終了し、I/Oエラーの性質を示すエラー・メッセージが発行されます。

*NEXTを指定すると、制御が次のコマンドに渡されます。*NEXTは、デフォルトのABORTを使用するのではなく、エラー・メッセージをRDMLで処理し、次にABORTで処理できるようにすることを目的としています(LANSA/ADおよびVisual LANSAの処理を続行することもできますが、この方法でLANSAを使用することはお勧めしません)。データベース操作から返されるERは致命的エラーです。この場合、LANSAは、処理が続行されないものと想定します。IOモジュールがリセットされ、以降のIOは、そのファイルでこれまでにIOが行われなかったかのように実行されます。そのため、ファイルの状態について推定を行わないでください。例えば、最後に読み取られたレコードは設定されません。IO_ERRORの特別なケースとして、TRIG_RETCでERを返すようトリガー・ファンクションがコード化されている場合があります。上記の説明は、このケースにも当てはまります。したがって、LANSAでは、さらにIOを実行する前にABORTまたはEXIT以外の何らかの処理を実行する目的で、トリガー・ファンクションから返された戻りコードERを使用しないことをお勧めします。

*RETURNを指定すると、プログラム・メインラインでは制御が呼び出し元に戻され、サブルーチンでは制御が呼び出し元ルーチンまたはプログラム・メインラインに戻されます。

上記の値をどれも使用しない場合は、制御を渡す先の有効なコマンド・ラベルを指定してください。

VAL_ERROR

このコマンドで妥当性検査エラーが検出された場合に実行するアクションを指定します。

妥当性検査エラーは、ファイルに対して追加、更新、または削除を行う情報が、そのファイル内のフィールドに関連付けられたFILEまたはDICTIONARYレベルの妥当性検査に合格しなかった場合に発生します。

デフォルト値*LASTDISを指定すると、直前の表示画面に制御が戻されます。この画面では、関連付けられた妥当性検査に失敗したフィールドが反転表示され、エラーのある最初のフィールドにカーソルが配置されます。

*NEXTを指定すると、制御が次のコマンドに渡されます。

*RETURNを指定すると、プログラム・メインラインでは制御が呼び出し元に戻され、サブルーチンでは制御が呼び出し元ルーチンまたはプログラム・メインラインに戻されます。

上記の値をどれも使用しない場合は、制御を渡す先の有効なコマンド・ラベルを指定してください。

*LASTDISは、「直前の表示画面」がない場合(バッチ・ファンクション内など)でも有効です。この場合、ファンクションが異常終了し、該当するエラー・メッセージが発行されます。

*LASTDISを使用する場合、「直前の表示画面」は、データベース・コマンド(INSERT、UPDATE、DELETE、FETCH、およびSELECT)と同じレベルでなければなりません。データベース・コマンドがSUBROUTINE内で指定され、「直前の表示画面」が呼び出し元ルーチンまたはメインラインの場合など、レベルが異なるとこのファンクションは異常終了し、該当するエラー・メッセージが発行されます。

これは、Visual LANSAでイベント・ルーチンとメソッド・ルーチンを使用する場合には当てはまりません。これらの場合、制御は呼び出しルーチンに戻されます。フィールドには、エラーがあることと、フォームの親階層で見つかった最初のステータス・バーに返されたメッセージが表示されます。または、メッセージがない場合は、実行スタック内で見つかったステータス・バーを持つ最初のフォーム(PRIM_OBJTから継承した再利用可能パーツなど)が表示されます。

NOT_FOUND

ファイル内で更新対象のレコードが見つからなかった場合に実行するアクションを指定します。

*NEXTを指定すると、制御が次のコマンドに渡されます。

*RETURNを指定すると、プログラム・メインラインでは制御が呼び出し元に戻され、サブルーチンでは制御が呼び出し元ルーチンまたはプログラム・メインラインに戻されます。

上記の値をどれも使用しない場合は、制御を渡す先の有効なコマンド・ラベルを指定してください。

ISSUE_MSG

「レコードが見つからない」メッセージを自動的に発行するかどうかを指定します。

デフォルト値*NOを指定すると、メッセージは発行されません。

*NO以外に指定できる値は*YESのみです。この値を指定すると、メッセージが自動的に発行されます。メッセージは、ユーザーに表示される次の画面形式の22/24行目、またはバッチ・ジョブのジョブ・ログに表示されます。

WITH_RRN

更新するレコードの相対レコード番号(相対レコード・ファイル処理のための番号)を保持するフィールドの名前を指定します。

WITH_RRNパラメータとWITH_KEYパラメータを両方使用することはできません。

このパラメータで指定するフィールドは、数値タイプで、このファンクションまたはLANSAデータ・ディクショナリで定義されていなければなりません。

注：FETCH、DELETE、またはUPDATEコマンドに対してWITH_RRNパラメータを使用すると、他の形式のデータベース・アクセスよりレコードの取得、削除、または更新を高速に行えます。

このコマンドで指定するファイルが論理ファイルかどうかに関係なく、実際にアクセス対象になるデータベース・ファイルは物理ファイルです。そのため、WITH_RRNパラメータを使用して論理ファイルにアクセスする場合は、論理ファイルの選択/除外基準は使用されません。

以下も参照してください。

「7.125.2 UPDATE についてのコメント/警告」に記載されている、このパラメータの使用による自動「相互更新」検査への影響の詳細
『Visual LANSA開発者ガイド』の「外部ファイルの読み込み」

RETURN_RRN

更新されたレコードの相対レコード番号を返す先のフィールドの名前を指定します。UPDATEコマンドによってファイル内の複数のレコードを更新した場合は、このフィールドに返される値を使用できません。

このパラメータで指定するフィールドは、数値タイプで、このファンクションまたはLANSAデータ・ディクショナリで定義されていなければなりません。

詳細については、『Visual LANSA開発者ガイド』の「外部ファイルの読み込み」を参照してください。

CHECK_ONLY

I/O操作を実際に実行するか、実際に実行したときにファイルおよびデータ・ディクショナリ・レベルの妥当性検査の条件をすべて満たすことができるかを検査するために「シミュレーション」のみを行うかを指定します。

デフォルト値*NOを指定した場合、I/O操作は通常の方法で実行されます。

*YESを指定した場合、ファイルおよびデータ・ディクショナリ・レベルの検査の条件をすべて満たすことができるかどうかを確認するために、I/O操作がシミュレートされます。このオプションを使用した場合、この検査に関与するデータベース・ファイルがいかなる形でも変更されることはありません。

AUTOCOMMIT

LANSAリリース4.0プログラム変更レベルE5により、このパラメータは、他のパラメータと機能が重複しています。

コミット制御を使用するには、アプリケーションでCOMMITまたはROLLBACKコマンド、あるいはその両方を指定してください。

通常は、COMMITコマンドのみが必要です。

IBM iでのコミット制御の関連については、『LANSA /ADユーザーガイド』の「コミット制御を使用する」を参照してください。

移植性に関する考慮事項

Visual LANSAを使用している場合は、『LANSAアプリケーション設計ガイド』の「コミット制御」を参照してください。

WITH_UPDID

更新する行の更新 ID 列と比較する更新 ID 列を含むフィールドの名前を指定します。

WITH_KEY または WITH_RRN が指定されている場合にのみ有効です。

このパラメータで指定されるフィールドはすべて、RDML または LANSA データディクショナリ内で定義され、数値である必要があります。

テーブルに LANSA 更新 ID 列が含まれる場合にのみ有効です。

RDMLX コードでのみ有効です。

警告：

交差更新チェック

UPDATE コマンドによる「クロス更新」チェックの使用を明確に理解する必要があります。更新が発行されると、WITH_KEY も WITH_RRN も指定されていない場合は自動的に「クロス更新」チェックが行われるか、WITH_UPDID が指定されている場合は明示的に「クロス更新」チェックが行われるか、WITH_UPDID なしで WITH_KEY または WITH_RRN が指定されている場合は実質的にクロス更新チェックが行われない場合があります。。

I/O が、IBM i のすべてのフィールド名が含まれていない論理ビューを使用している場合、IBM i で IBM i の「その他」ファイルを使用して自動「クロス更新」チェックを試行すると、誤った「クロス更新」エラーが発生することに注意してください。

自動相互更新チェック

次のコマンドフローを考えてみましょう。


     FETCH WITH_KEY( ) or WITH_RRN( )
     DISPLAY
     ...
     UPDATE (no WITH_KEY and no WITH_RRN)

UPDATE コマンドには WITH_KEY または WITH_RRN パラメータがないため、(FETCH コマンドによって) 読み取られた最後の行を削除する必要があることを示します。

この状況では、「交差更新ウィンドウ」は、行が FETCH された時点から UPDATE された時点までの間隔にあります。

注意： これには時間がかかる場合があります。

これは、自動「クロス更新」チェック機能の正しく有効な使用法です。 FETCH と UPDATE の間に別のジョブ/ユーザーによって行が変更された場合、UPDATE によって「クロス更新エラー」が生成されます (これは、他の種類の検証エラーと同様に処理する必要があります)。

明示的な相互更新チェック

次のコマンドフローを考えてみましょう。

インタラクション 1

     FETCH RET_UPDID( ) WITH_KEY( ) または WITH_RRN( )

インタラクション 2 (同じ「ジョブ」または異なる「ジョブ」)

     UPDATE WITH_UPDID( ) WITH_KEY( ) または WITH_RRN( )

この状況では、「交差更新ウィンドウ」は行が FETCH された時間と UPDATE が行われた時間の間の間隔にありますが、この場合、同じ「ジョブ」内で発生しているわけではない可能性があります。

繰り返しますが、ユーザーが対話の合間にコーヒーを飲みに行った場合、これは非常に長くなる可能性があります。

これは、FETCH と UPDATE の両方の WITH_KEY が同じ行に対して機能する限り、明示的な「クロス更新」チェック機能の正しく有効な使用法です。その行が FETCH と UPDATE の間に別のジョブ/ユーザーによって変更された場合、UPDATE は「クロス更新エラー」を生成します (これは他の種類の検証エラーと同様に処理する必要があります)。

交差更新チェックなし

次のコマンドフローを考えてみましょう。

     FETCH WITH_KEY( ) または WITH_RRN( )
     DISPLAY
     ...
     UPDATE WITH_KEY( ) または WITH_RRN( ) (ただし WITH_UPDIDは不可)

UPDATE コマンドには WITH_KEY または WITH_RRN パラメーターがありますが、WITH_UPDID パラメーターがないため、特定の行 (または行のグループ) を読み取って更新する必要があることを示します。

自動の「交差更新」チェックを期待するのは、よくあるコーディングミスです。 UPDATE コマンドの WITH_KEY または WITH_RRN 値が FETCH コマンドの値と同じである必要があることは誰もが知っています。ただし、RDML コンパイラは、FETCH コマンドの実行後に値が変更されていないことを確認できないため、UPDATE を試行する前に行を (再) 読み取る必要があります。

この状況では、「交差更新ウィンドウ」は、行が UPDATE コマンドによって (再) 読み取られてから、UPDATE コマンドによって更新されるまでの間隔にあります。この間隔は非常に短いため、「クロス更新」チェックは事実上無効になります。

これは、自動の「クロス更新」チェックを実質的に無効にするため、このような対話型シナリオでの UPDATE コマンドの有効かつ正しい使用とは見なされません。

鍵なし

UPDATE コマンドに WITH_KEY または WITH_RRN パラメーターが指定されていない場合、テーブルから読み取られた最後の行が更新されます。これらは同等の操作です。

     CHANGE FIELD(#DATDUE) TO(*DATE)
     UPDATE FIELDS(#DATDUE) IN_FILE(ORDHDR) WITH_KEY(#ORDNUM

機能的には以下と同等です。

     FETCH FIELDS(#DATDUE) FROM_FILE(ORDHDR) WITH_KEY(#ORDNUM)
     CHANGE FIELD(#DATDUE) TO(*DATE)
     UPDATE FIELDS(#DATDUE) IN_FILE(ORDHDR)

そして：

     CHANGE FIELD(#QUANTITY) TO100)
     UPDATE FIELDS(#QUANTITY) IN_FILE(ORDLIN) WITH_KEY(#ORDNUM)

機能的には以下と同等です。

     SELECT FIELDS(#QUANTITY) FROM_FILE(ORDLIN) WITH_KEY(#ORDNUM)
     CHANGE FIELD(#QUANTITY) TO100)
     UPDATE FIELDS(#QUANTITY) IN_FILE(ORDLIN)
     ENDSELECT

最後の 2 つの例では、注文のすべての注文明細行の #QUANTITY フィールド名が 100 に変更されることに注意してください。これは、複数行更新または「一度に設定」更新の例です。

注意： UPDATE WITH_KEY は、同じテーブルまたはビューの選択ループ内、または選択ループ内から呼び出されるサブルーチン内で使用してはなりません。

Content

Space Tools

7.125.1 UPDATE のパラメータ

Content

Space Tools

UPDATE_P

7.125.1 UPDATE のパラメータ