4.3.3 簡単な問い合わせ処理(データ修正機能を追加)

ここでは前節の問い合わせ処理ファンクションを改訂して、レコードの保守(データの修正)もできるようにします。

処理対象ファイル

物理ファイル「CUSMST」(顧客マスター)

RDMLプログラム

GROUP_BY   NAME(#CUSTOMER) FIELDS((#CUSTNO *NOCHG) 
           #NAME #ADDL1 #ADDL2 #ADDL3)

BEGIN_LOOP

REQUEST    FIELD(#CUSTNO)
FETCH      FIELDS(#CUSTOMER) FROM_FILE(CUSMST) 
           WITH_KEY(#CUSTNO)

    IF_STATUS  IS(*OKAY)
    SET_MODE   TO(*DISPLAY)
    DISPLAY    FIELDS(#CUSTOMER) CHANGE_KEY(*YES)

        IF_MODE IS(*CHANGE)
        UPDATE  FIELDS(#CUSTOMER) IN_FILE(CUSMST) 
                VAL_ERROR(*LASTDIS)
        ENDIF

    ELSE
    MESSAGE    MSGTXT('No customer exists with this number')
    ENDIF

END_LOOP

 

着目点：

• 顧客情報の問い合わせのほか、修正もできるよう改訂しました。

• BEGIN_LOOP～END_LOOPのブロック内で、ファンクション・キーEXITまたはMENUが押されるまでの間、検索/修正処理を繰り返します。

• ファンクション・キーEXITとMENUは、デフォルトでREQUEST/DISPLAY/POPUP画面に表示されます。いずれかのキーを押すとファンクションは終了します。

• さらにDISPLAY画面では、ファンクション・キーCHANGEも使えるようになっています。このキーを押すと、モードが*CHANGEに変わり、画面が再描画されて、#CUSTNO以外のフィールドがすべて入力を受け付けるようになります。#CUSTNOが入力を受け付けないのは、GROUP_BYコマンドで#CUSTNOに*NOCHG属性が設定されているからです。

• DISPLAYコマンドが完了した後、モードのテストが行われます。*CHANGEモードであれば、画面上で顧客データが修正され、ファンクション・キーCHANGEが押された、ということになります。したがって、UPDATEコマンドを使って、顧客マスター・ファイルを更新します。UPDATEコマンドの実行中に(ファイル単位またはフィールド単位の)妥当性規則違反を検出した場合、画面にエラーの詳細が表示されます。これはVAL_ERROR(*LASTDIS)というパラメータの働きによるものです。

• UPDATEコマンドには、更新対象レコードを表すWITH_KEYパラメータが指定されていません。これは、ファイルから読み込んだ最新のレコード、すなわち、直前にFETCHコマンドで読み込んだレコードを更新することを表します。

• LOCK(*YES) パラメータの指定がないので、FETCH コマンドから UPDATE コマンドまでの間、レコードはロックされません。

したがって、他のユーザーが、この間に同じレコードを更新してしまうこともありえます。作業中に昼休みになった場合など、ロックされない状態で30分以上放置されることもあるので、問題が起こりそうに見えます。

しかしCUSMSTの作成や保守にLANSAを使っている場合、問題が起こることはありません。UPDATEコマンドは自動的に、読み込みから更新までの間にレコードが更新されていないか確認するようになっているからです。この間に他のユーザーが同じレコードを更新していた場合、UPDATEコマンドを実行しようとするとエラーとなり、更新が拒絶されたことを示すメッセージが自動的に表示されます。DISPLAY画面が再び表示され、エラー・メッセージが示されます。