ここでは前節の問い合わせ処理ファンクションを改訂して、レコードの保守(データの修正)もできるようにします。
物理ファイル「CUSMST」(顧客マスター)
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画面が再び表示され、エラー・メッセージが示されます。