Page History
...
このパラメータで指定するフィールドは、数値タイプで、このファンクションまたはLANSAデータ・ディクショナリで定義されていなければなりません。
| Note |
|---|
注：注意：FETCH、DELETE、またはUPDATEコマンドに対してWITH_RRNパラメータを使用すると、他の形式のデータベース・アクセスよりレコードの取得、削除、または更新を高速に行えます。 |
...
RDMLX コードでのみ有効です。
| Warning |
|---|
警告：
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 された時点までの間隔にあります。 |
...
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 コマンドによって更新されるまでの間隔にあります。 この間隔は非常に短いため、「クロス更新」チェックは事実上無効になります。
...