Summary

Summary

FRM035 - Maintain a Simple Database Table

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 the record if you are not using a key to identify the record. For more details about cross-update and delete, please search for Cross Update notes in the Technical Reference Guide. For example see UPDATE Comments / Warnings / Understand UPDATE Command.

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

Tips & Techniques

• The CHECK_ONLY parameter on file commands allows you to check what would happen if the file 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 file 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 files in LANSA applications. In special circumstances, such as large application with hundreds of files 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 file be fetched.

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

• *ALL_VIRT specifies that all virtual fields from the currently active file 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 which 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 file 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 file 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.

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