BEGINCHECK / ENDCHECK blocks can be nested. However, if an "inner" block detects an error it also triggers an error in all associated "outer" blocks.
This can be illustrated like this:
BEGINCHECK
BEGINCHECK
BEGINCHECK
A validation error in this block will "trigger" a
validation error at all levels (marked by <-).
ENDCHECK <-
ENDCHECK <-
ENDCHECK <-
The ability to nest BEGINCHECK / ENDCHECK commands is particularly useful when processing screens that have browse lists that are used for data entry. Consider a data entry screen like this:
|
The RDML program to process data entered in this way might look something like this:
GROUP_BY NAME(#ORDERHEAD) FIELDS(#ORDNUM #CUSTNUM #DATEDUE)
DEF_LIST NAME(#ORDERLINE) FIELDS(#ORDLIN #PRODUCT #QUANTITY #PRICE)
SET_MODE TO(*ADD)
INZ_LIST NAMED(#ORDERLINE) NUM_ENTRYS(20)
L1: REQUEST FIELDS(#ORDERHEAD) BROWSELIST(#ORDERLINE)
BEGINCHECK
<< validate order header details >>
SELECTLIST NAMED(#ORDERLINE) GET_ENTRYS(*NOTNULL) <-
BEGINCHECK |
<< validate order line details >> |
IF_ERROR |
UPD_ENTRY IN_LIST(#ORDERLINE) |
ENDIF |
ENDCHECK IF_ERROR(*NEXT) |
|
ENDSELECT ------------------------------------------
ENDCHECK IF_ERROR(*LASTDIS)
<< update database >>
Note that the "inner" BEGINCHECK/ENDCHECK loop is processed for each browse list entry that the user entered. Note also that the IF_ERROR(*NEXT) parameter causes the SELECTLIST loop to continue to process all browse list entries and not stop the first time an error is detected.
The "outer" BEGINCHECK/ENDCHECK command uses the IF_ERROR(*LASTDIS) parameter which will cause the REQUEST command to be re-executed if a validation error is detected. A validation error will be "detected" if