Page History
...
|
|---|
Specifies either the field(s) that are to be fetched from the file or the name of a group that specifies the field(s) to be fetched. Alternatively, an expandable group expression can be entered in this parameter. For more details, refer to Expandable Groups.
The following special values can be used:
...
The recommended design when using BLOB and CLOB fields is to put them in a separate file from the rest of the fields using the same key as the main file. This forces programmers to do separate IOs to access the BLOB and CLOB data, thus reducing impact on database performance from indiscriminate use of this data. It is also the most portable design ensuring that the non-BLOB and non-CLOB data can be quickly accessed at all times.
|
|---|
efer to Specifying File Names in I/O commands.
|
|---|
efer to Specifying Conditions and Expressions and Specifying WHERE Parameter in I/O Commands.
After a fetch utilizing a where condition that results in a record not found, the contents of the fields are unpredictable.
|
|---|
efer to Specifying File Key Lists in I/O Commands.
|
|---|
pecifies the name of a field that is to receive the "return code" that results from the I/O operation.
...
For details of I/O operation return code values, refer to I/O Return Codes.
|
|---|
pecifies what action is to be taken if an I/O error occurs when the command is executed.
...
If none of the previous values are used you must nominate a valid command label to which control should be passed.
|
|---|
pecifies the action to be taken if a validation error was detected by the command.
...
| 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). |
|
|---|
pecifies what is to happen if no record is found in the file that has a key matching the key nominated in the WITH_KEY parameter.
...
If none of the previous values are used you must nominate a valid command label to which control should be passed.
|
|---|
pecifies whether a "not found" message is to be automatically issued or not.
...
The only other allowable value is *YES which indicates that a message should be automatically issued. The message will appear on line 22/24 of the next screen format presented to the user or on the job log of a batch job.
|
|---|
pecifies whether or not the record should be locked when it is read.
...
| Note |
|---|
| Note: LOCK(*YES) performs a record level lock. It may exhibit intra and inter operating system behavioural variations (e.g. commitment control locking multiple records; default wait times). User's are advised to investigate the development of proper and complete "user object" locking protocol by using the LOCK_OBJECT Built-In Function. |
Portability Considerations | Not supported and should not be used in portable applications. A build warning will be generated when used in Visual LANSA. |
|
|---|
Specifies the name of a field that contains the relative record number (for relative record file processing) of the record which is to be fetched. The WITH_RRN parameter cannot be used if the WITH_KEY or WHERE parameters are used.
...
For information, refer also to Load Other File in the Visual LANSA Developers Guide.
|
|---|
pecifies the name of a field in which the relative record number of the record just fetched should be returned.
...
For further information refer also to Load Other File in the Visual LANSA Developers Guide.
|
|---|
pecifies that details of the last "n" FETCH operations be kept within the compiled RDML program. Whenever a FETCH command is executed the details of the last "n" FETCH operations are searched first. If the required details are found within the program, no database I/O operation actually occurs. This can dramatically improve the performance of RDML programs.
...
| Info |
|---|
| Note also that since previous FETCH details are stored within the RDML program, it is possible for the actual database file details to be changed without the change being reflected in the RDML program. |
|
|---|
pecifies the name of a field in which the update id column of the row just fetched should be returned.
...