You can write just about any ABL code you want into a trigger procedure, but there are a few guidelines that can help you use them widely and effectively. You must decide the appropriate practice for your own application. These are recommendations that are generally useful:
  • Use trigger procedures sparingly, for truly global and non-changing integrity checks — Resist the temptation to write real business logic into a trigger procedure. Basic integrity constraints are themselves a part of your business logic, of course, but you can think of business logic in this sense as being rules that are complex, subject to change, different for different customers or user groups, or otherwise difficult to pin down precisely.
  • Always remember that trigger procedures execute on the server-side of a distributed application — Never put messages into a trigger procedure, for example, because they are not seen on the client. A trigger procedure should never have any user interface or contain any statements that could possibly block the flow of the application, such as a statement that requests a value.
  • Remember that trigger procedures operate in the background of an application — That is, you do not see the trigger code itself when you are looking through the procedures that make up your application, so it is important that they not have surprising or strange effects. If a trigger verifies a Customer Number in an Order record in a consistent way, developers come to see this as a welcome check and understand why it is there and what it is doing. If you put complex or obscure code into a trigger procedure, you might confuse developers who cannot understand why the application procedures they are coding or looking at are executing in a strange way.
  • Return errors in a standard way from all your triggers — If a trigger procedure does an integrity check, it must be able to reject the record update that fired it. Without being able to display a message, your procedure must generate the error in a way that application code can deal with it consistently. One method is to RETURN ERROR with a message that becomes the RETURN-VALUE of the trigger and code your application to be prepared to handle errors of this kind, by taking the RETURN-VALUE and turning it into a standard message box on the client, for example. Alternatively, you can use RETURN ERROR error-object with the message embedded in the object.
  • Write your applications so that errors from triggers are as unlikely as possible — You should use integrity procedures as a last defense for your application to make sure that casually written procedures do not compromise your database. The heart of your application logic should enforce all integrity at a level that is visible to the application. Where appropriate, you can take specific actions when errors occur, and when updates change other database values that the user might need to see. For example, the user interface for your Order Entry screen probably should present the user with a lookup list of some sort to choose a Customer from, where the Customer Name or other identifying information verifies that the Customer Number is correct. If you do this, then it is very unlikely that an invalid CustNum will find its way back to an actual update to be detected and rejected by a trigger procedure.