Page History
...
テーブルに LANSA 更新 ID 列が含まれる場合にのみ有効です。
RDMLX コードでのみ有効です。
| Warning |
|---|
警告: |
...
DELETE |
...
コマンドによる「相互更新」チェックの使用を明確に理解する必要があります。 DELETE が発行されると、WITH_KEY と WITH_RRN |
...
が指定されていない場合は自動的に「相互更新」チェックが行われます。 |
...
が指定されていた場合は、明示的に「相互更新」チェックが行われます。 |
...
が指定されておらず、 WITH_KEY または WITH_RRN |
...
が指定されている場合は実質的に相互更新チェックが行われません。 I/O がテーブル内のすべてのフィールド名を含まない論理ビューを使用している場合、IBM i の「その他」ファイルを使用して IBM i |
...
上で自動化された「相互更新」チェックを試行すると、誤った「相互更新」エラーが発生することに注意してください。
|
...
この状況では、「相互更新ウィンドウ」は、行が FETCH された時点から DELETE された時点までの間隔にあります。 |
| Note |
|---|
注意: これには時間がかかる場合があります。 |
...
DELETE WITH_UPDID( ) WITH_KEY( ) or WITH_RRN( )
この状況では、「交差更新ウィンドウ」は行が この状況では、「相互更新ウィンドウ」は行が FETCH された時間と DELETE が行われた時間の間の間隔にありますが、この場合、同じ「ジョブ」内で発生しているわけではない可能性があります。
...
これは、FETCH と DELETE の両方の WITH_KEY が同じ行に対して機能する限り、明示的な「クロス更新」チェック機能の正しく有効な使用法です。 が同じ行に対して機能する限り、明示的な「相互更新」チェック機能の正しく有効な使用法です。 その行が FETCH と DELETE の間に別のジョブ/ユーザーによって変更された場合、DELETE によって「交差更新エラー」が生成されます によって「相互更新エラー」が生成されます (これは他の種類の検証エラーと同様に処理する必要があります)。
- 交差更新チェックなし相互更新チェックなし
次のコマンド フローを考えてみましょう。
FETCH WITH_KEY( ) または WITH_RRN( )
DISPLAY
...
DELETE WITH_KEY( ) または WITH_RRN( ) (ただし、WITH_UPDID はなし)
DELETE コマンドには WITH_KEY または WITH_RRN パラメータがありますが、WITH_UPDID パラメータがないため、特定の行 (または行のグループ) を読み取って削除する必要があることを示します。
これは、自動の「交差更新」チェックを期待するためによくあるコーディングミスです。 これは、自動の「相互更新」チェックを期待するためによくあるコーディングミスです。 DELETE コマンドの WITH_KEY または WITH_RRN 値は、FETCH コマンドの値と同じである必要があります。 ただし、RDML コンパイラは、FETCH コマンドの実行後に値が変更されていないことを確認できないため、DELETE を試行する前に行を (再) 読み取る必要があります。
この状況では、「交差更新ウィンドウ」は、行が この状況では、「相互更新ウィンドウ」は、行が DELETE コマンドによって (再) 読み取られてから、DELETE コマンドによって削除されるまでの間隔にあります。 この間隔は非常に短いため、「交差更新」チェックは事実上無効になります。この間隔は非常に短いため、「相互更新」チェックは事実上無効になります。
これは、自動の「交差更新」チェックを実質的に無効にするため、対話型シナリオでの これは、自動の「相互更新」チェックを実質的に無効にするため、対話型シナリオでの DELETE コマンドの有効かつ正しい使用とは見なされません。
...