Page History
...
ファイル内の更新するフィールド、または更新するフィールドを指定するグループの名前を指定します。 拡張可能なグループ式を指定することもできます。詳細については、「フィールド・グループおよび拡張可能なグループ」を参照してください。以下の特別な値を指定できます。
拡張可能なグループ式を指定することもできます。詳細については、「フィールド・グループおよび拡張可能なグループ」を参照してください。以下の特別な値を指定できます。
- *ALLを指定した場合、現在アクティブなファイルのすべてのフィールドが更新されます。
- *ALL_REALを指定した場合、現在アクティブなファイルのすべての実フィールドが更新されます。
- *ALL_VIRTを指定した場合、現在アクティブなファイルのすべての仮想フィールドが更新されます。
- *EXCLUDINGを指定した場合、この特別な値に続けて指定するフィールドがフィールド・リストから除外されます。
- *INCLUDINGを指定した場合、この特別な値に続けて指定するフィールドがフィールド・リストに含められます。この特殊な値は、*EXCLUDINGエントリーによって、フィールド・リストが除外モードに移行した後にのみ必要です。
...
移植性に関する考慮事項 | IBM iで、コミット制御下にないファイルの1つ以上のLOBフィールドを更新する場合にI/Oエラーが発生すると、LOB以外のフィールドが更新され、1つ以上のLOBフィールドが更新されない可能性があります。 |
|
|---|
「I/Oコマンドでのファイル名の指定」を参照してください。「I/Oコマンドでのファイル名の指定」を参照してください。
|
|---|
「I/Oコマンドでのファイル・キー・リストの指定」を参照してください。「I/Oコマンドでのファイル・キー・リストの指定」を参照してください。
このパラメータによる自動「相互更新」検査への影響の詳細については、次のコメント/警告のセクションを参照してください。
...
戻りコードを受け取るフィールドとしてユーザー・フィールドを指定する場合、このフィールドは、長さ2文字の英数字フィールドである必要があります。ユーザー・フィールドを指定した場合も、特別なフィールド#IO$STSは更新されます。
I/O操作の戻りコードについては、「I/Oコマンド戻りコード表」を参照してください。O操作の戻りコードについては、「I/Oコマンド戻りコード表」を参照してください。
|
|---|
...
このコマンドで指定するファイルが論理ファイルかどうかに関係なく、実際にアクセス対象になるデータベース・ファイルは物理ファイルです。そのため、WITH_RRNパラメータを使用して論理ファイルにアクセスする場合は、論理ファイルの選択/除外基準は使用されません。
以下も参照してください。
- 「7.125.2 UPDATE についてのコメント/警告」に記載されている、このパラメータの使用による自動「相互更新」検査への影響の詳細
- 『Visual LANSA開発者ガイド』の「外部ファイルの読み込み」LANSA開発者ガイド』の「インポート・テーブル定義」
|
|---|
...
詳細については、『Visual LANSA開発者ガイド』の「外部ファイルの読み込み」を参照してください。の「インポート・テーブル定義」を参照してください。
|
|---|
...
IBM iでのコミット制御の関連については、『LANSA /ADユーザーガイド』の「コミット制御を使用する」を参照してください。の「コミット制御を使用する」を参照してください。
|
|---|
...
RDMLX コードでのみ有効です。
| Warning |
|---|
警告：
UPDATE コマンドによる「クロス更新」チェックの使用を明確に理解する必要があります。 コマンドによる「相互更新」チェックの使用を明確に理解する必要があります。 更新が発行されると、WITH_KEY も WITH_RRN も指定されていない場合は自動的に「クロス更新」チェックが行われるか、WITHも指定されていない場合は自動的に「相互更新」チェックが行われるか、WITH_UPDID が指定されている場合は明示的に「クロス更新」チェックが行われるか、WITHが指定されている場合は明示的に「相互更新」チェックが行われるか、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 によって「クロス更新エラー」が生成されます によって「相互更新エラー」が生成されます (これは、他の種類の検証エラーと同様に処理する必要があります)。
...
これは、FETCH と UPDATE の両方の WITH_KEY が同じ行に対して機能する限り、明示的な「クロス更新」チェック機能の正しく有効な使用法です。 が同じ行に対して機能する限り、明示的な「相互更新」チェック機能の正しく有効な使用法です。 その行が FETCH と UPDATE の間に別のジョブ/ユーザーによって変更された場合、UPDATE は「クロス更新エラー」を生成します は「相互更新エラー」を生成します (これは他の種類の検証エラーと同様に処理する必要があります)。
...
この状況では、「相互更新ウィンドウ」は、行が UPDATE コマンドによって (再) 読み取られてから、UPDATE コマンドによって更新されるまでの間隔にあります。 この間隔は非常に短いため、「クロス更新」チェックは事実上無効になります。この間隔は非常に短いため、「相互更新」チェックは事実上無効になります。
これは、自動の「クロス更新」チェックを実質的に無効にするため、このような対話型シナリオでの これは、自動の「相互更新」チェックを実質的に無効にするため、このような対話型シナリオでの UPDATE コマンドの有効かつ正しい使用とは見なされません。
...