Page History
...
|
|---|
ファイル内の更新するフィールド、または更新するフィールドを指定するグループの名前を指定します。
...
- *ALLを指定した場合、現在アクティブなファイルのすべてのフィールドが更新されます。
- *ALL_REALを指定した場合、現在アクティブなファイルのすべての実フィールドが更新されます。
- *ALL_VIRTを指定した場合、現在アクティブなファイルのすべての仮想フィールドが更新されます。
- *EXCLUDINGを指定した場合、この特別な値に続けて指定するフィールドがフィールド・リストから除外されます。
- *INCLUDINGを指定した場合、この特別な値に続けて指定するフィールドがフィールド・リストに含められます。この特殊な値は、*EXCLUDINGエントリーによって、フィールド・リストが除外モードに移行した後にのみ必要です。
| Infonote |
|---|
注：注意：OTHERによって保守されている論理ファイルからすべてのフィールドを更新すると、基になっている物理ファイルのすべてのフィールドがフィールド・リストに含められます。 |
パラメータFIELDSでは、特別な値*ALL、*ALL_REAL、または*ALL_VIRTを必要な場合にのみ慎重に使用することを強くお勧めします。必要のないフィールドを更新すると、クロスリファレンスの詳細(ファンクション内で使用されていないフィールドを示す)が無効になり、ファンクションのCRUDE項目の複雑度が無意味に高くなります。
移植性に関する考慮事項 | IBM iで、コミット制御下にないファイルの1つ以上のLOBフィールドを更新する場合にI/Oエラーが発生すると、LOB以外のフィールドが更新され、1つ以上のLOBフィールドが更新されない可能性があります。 『LANSAアプリケーション設計ガイド』の「コミット制御」も参照してください。 |
...
移植性に関する考慮事項 | Visual LANSAを使用している場合は、『LANSAアプリケーション設計ガイド』の「コミット制御」を参照してください。 |
更新する行の更新 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 の「その他」ファイルを使用して自動「相互更新」チェックを試行すると、誤った「相互更新」エラーが発生することに注意してください。
- 自動相互更新チェック
次のコマンド フローを考えてみましょう。
...
UPDATE コマンドには WITH_KEY または WITH_RRN パラメータがないため、(FETCH コマンドによって) 読み取られた最後の行を削除する必要があることを示します。
この状況では、「相互更新ウィンドウ」は、行が FETCH された時点から UPDATE された時点までの間隔にあります。
Note 注意： これには時間がかかる場合があります。
これは、自動「相互更新」チェック機能の正しく有効な使用法です。 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 に変更されることに注意してください。これは、複数行更新または「一度に設定」更新の例です。
...