Summary

Important Observations

• GROUP_BY commands help you simplify your code.

• You should always check the I/O status after performing database operations. The IF_STATUS command supports *OKAY, *ERROR, *VALERROR, *NORECORD, *ENDFILE, *BEGINFILE, *EQUALKEY, *NOTEQUALKEY.

• Program level validation rules can be added using a BEGINCHECK / ENDCHECK and related validation commands CALLCHECK, CONDCHECK, DATECHECK, FILECHECK, RANGECHECK, VALUECHECK, IF_ERROR, SET_ERROR.

• A record should be fetched from the database prior to updating or deleting it, if you are not using a key to identify the record. For more details about cross-update and delete, please refer to
  DELETE Comments / Warnings and Understand the UPDATE Command in UPDATE Comments / Warnings in the Technical Reference Guide.

• LANSA provides many Built-In Functions that can be used to perform specialized tasks in LANSA. Intrinsic field methods are now used in place of many of these Built in Functions.

• The SUBROUTINE / ENDROUTINE defines a routine that you can EXECUTE from any other routine in your form. Subroutines cannot be defined within an event, method or property routine.

Tips & Techniques

• The CHECK_ONLY parameter on table I/O commands allows you to check what would happen if the table operation is performed but the operation is not actually performed. For example, you can use CHECK_ONLY(*YES) on the delete command to check if a record can be deleted from a table without actually performing the delete.

• The ISSUE_MSG parameter on the FETCH commands will only display a message if a record is not found. It is generally better to check the IO$STS or use the IF_STATUS and then display messages to the user.

• Typically, you do not need to open or close tables in LANSA applications. In special circumstances, such as large application with hundreds of tables being accessed, you may wish to use the OPEN and CLOSE statements.

• Special values can be used with the database commands such as FETCH, INSERT and UPDATE. For example, the following values can be used with the FETCH command:

• *ALL specifies that all fields from the currently active table be fetched.

• *ALL_REAL specifies that all real fields from the currently active table be fetched.

• *ALL_VIRT specifies that all virtual fields from the currently active table be fetched.

• *EXCLUDING specifies that fields following this special value must be excluded from the field list.

• *INCLUDING specifies that fields following this special value must be included in the field list. This special value is only required after an *EXCLUDING entry has caused the field list to be in exclusion mode.

• It is strongly recommended that the special values *ALL, *ALL_REAL or *ALL_VIRT be used sparingly and only when really required. Fetching fields that are not needed causes the function to retrieve and map fields unnecessarily, invalidates cross-reference details (shows fields which are not used in the function) and increases the Crude Entity Complexity Rating of the function.

• Most of your validation checks should be performed using table level validation rules in the Repository. Your program level validations support *ERROR, *NEXT and *ACCEPT processing similar to the repository checks.

What You Should Know

• How to use the FETCH, INSERT, UPDATE and DELETE database commands.

• How to handle errors using the IF_STATUS command when performing table operations.

• How to code program level validations using BEGINCHECK / ENDCHECK, CONDCHECK, FILECHECK, RANGECHECK, VALUECHECK, IF_ERROR, and SET_ERROR.

• How program validations relate to the repository validation performed by the Object Access Modules (OAM).

• How to use a Built-In Function to display a message box with user confirmation.