Page History
...
If none of the previous values are used you must nominate a valid command label to which control should be passed.
| Info |
|---|
| The *LASTDIS is valid even if there is no "last display" (such as in batch functions). In this case the function will abort with the appropriate error message(s). When using *LASTDIS the "Last Display" must be at the same level as the database command (INSERT, UPDATE, DELETE, FETCH and SELECT). If they are at different levels e.g. the database command is specified in a SUBROUTINE, but the "Last Display" is a caller routine or the mainline, the function will abort with the appropriate error message(s). The same does NOT apply to the use of event routines and method routines in Visual LANSA. In these cases, control will be returned to the calling routine. The fields will display in error with messages returned to the first status bar encountered in the parent chain of forms, or if none exist, the first form with a status bar encountered in the execution stack (for example, a reusable part that inherits from PRIM_OBJT). |
|
|---|
...
Any field nominated in this parameter must be defined within the function or the LANSA data dictionary and must be numeric.
| Info |
|---|
| Using the WITH_RRN parameter to FETCH, DELETE or UPDATE records is faster than any other form of database access. |
The actual database file being accessed is always the physical file, regardless of whether or not the file nominated in the command is a logical file. Thus logical file select/omit criteria are not used when accessing a logical file via the WITH_RRN parameter.
...
For the implications of using commitment control on the IBM i, refer to Commitment Control in the LANSA for i User Guide.
Portability Considerations | If using Visual LANSA, refer to Commitment Control in the LANSA Application Design Guide. |
...
Crossed Update Checks
The use of "crossed update" checks by the DELETE command must be clearly understood. When a DELETE is issued, there is an automatic "crossed update" checking if no WITH_KEY and no WITH_RRN are specified, or an explicit "crossed update" checking if WITH_UPDID is specified, or effectively no "crossed update" checking if WITH_KEY or WITH_RRN are specified without WITH_UPDID.
Note that a false "crossed update" error will occur if an automated "crossed update" checking is attempted on IBM i with an IBM i "Other" file if the I/O is using a logical view that does not contain all field names in the table.
Automatic crossed update checks
Consider this flow of commands:
FETCH WITH_KEY( ) or WITH_RRN( )
DISPLAY
...
DELETE (no WITH_KEY and no WITH_RRN)Since the DELETE command has no WITH_KEY or WITH_RRN parameter, it is indicating that the last row read (by the FETCH command) should be deleted.
In this situation, the "crossed update window" is in the interval between the time the row was FETCHed and the time it is DELETEd.
Note Note: This may take some time. This is a correct and valid use of the automatic "crossed update" checking facility. If the row is changed by another job/user between the FETCH and the DELETE, the DELETE will generate a "crossed update error" (which must be handled like any other type of validation error).
Explicit crossed update checks
Consider this flow of commands:
Interaction 1
FETCH RET_UPDID( ) WITH_KEY( ) or WITH_RRN( )
Interaction 2 (same "job" or different "job")
DELETE WITH_UPDID( ) WITH_KEY( ) or WITH_RRN( )
In this situation, the "crossed update window" is in the interval between the time the row was FETCHed and the time it was DELETEd, but in this case, it may not be occurring in the same "job"
Note Note: This may take some time. This is a correct and valid use of the explicit "crossed update" checking facility, as long as the WITH_KEY, for both FETCH and DELETE, acts on the same row. If that row is changed by another job/user between the FETCH and the DELETE, the DELETE will generate a "crossed update error" (which must be handled like any other type of validation error).
No crossed update checks
Consider this flow of commands:
FETCH WITH_KEY( ) or WITH_RRN( )
DISPLAY
...
DELETE WITH_KEY( ) or WITH_RRN( ) (but no WITH_UPDID)Since the DELETE command has a WITH_KEY or WITH_RRN parameter but no WITH_UPDID parameter, it indicates that a specific row (or group of rows) should be read and deleted.
This is a frequent coding mistake to expect an automatic "crossed update" checking. The WITH_KEY or WITH_RRN values on the DELETE command must be the same as those on the FETCH command. However, the RDML compiler cannot be sure that the values have not been changed since the FETCH command was executed, so it is forced to (re)read the row before attempting the DELETE.
In this situation, the "crossed update window" is in the interval between the time the row is (re)read by the DELETE command and then deleted by the DELETE command. This interval is very short, thus the "crossed update" check is effectively disabled.
This is not considered a valid and correct use of the DELETE command in an interactive scenario because it effectively disables the automatic "crossed update" check.
No KEY
When a DELETE command has no WITH_KEY, WHERE, or WITH_RRN parameters specified, the last row read from the table will be deleted. These are equivalent operations:
DELETE FROM_FILE(ORDHDR) WITH_KEY(#ORDNUM
is functionally equivalent to:
FETCH FROM_FILE(ORDHDR) WITH_KEY(#ORDNUM)
DELETE FROM_FILE(ORDHDR)and:
DELETE FROM_FILE(ORDLIN) WITH_KEY(#ORDNUM)
Is functionally equivalent to:
SELECT FROM_FILE(ORDLIN) WITH_KEY(#ORDNUM)
DELETE FROM_FILE(ORDLIN)
ENDSELECTNote that the last 2 examples delete all order lines for the order. This is an example of multiple rows deleting or "set at a time" deleting.
Note DELETE WITH_KEY or WHERE must not be used within a select loop for the same table or view in a subroutine called from within the select loop.