Time to get trigger-happy (not in the western-movie way) as I’ll introduce you to your new best friend: the SQL trigger. Keep reading to find out what I’m talking about!

If you’re not familiar with the trigger concept in IBM i’s context, it is a Big Brother–like “thing” that keeps an eye on a table and, when a certain operation occurs, performs a predefined action. In a silly analogy, if a table was one of Pavlov’s dogs, and the INSERT/UPDATE/DELETE operation was the light the scientist controlled, then the trigger would be the reflex action causing the dog to come running and start drooling.

In a time when business applications are increasingly intertwined, it’s hard to keep track of events to make sure a certain action is met with the appropriate reaction. Consider an order-entry application. In the old days, there was only one way to enter orders in the system: an IBM i program. Today, the front-end of the application can be a web, mobile, or client/server application, which makes reacting to a new order much more complex.

Naturally, you can write specific code on each platform to perform the same actions, but that’s not very productive. Creating a trigger over the order master table that reacts to an INSERT or UPDATE operation and performs the necessary actions is much simpler and effective. There’s only one piece of code to maintain, and there’s also the guarantee that the necessary actions will be performed even when there’s a new interface writing data to the table.

Triggers are application-independent. They are user-written programs that are activated by the database manager when a data change is performed in the database. Once a trigger is in place, programmers and end users cannot circumvent it. When a trigger is activated, the control shifts from the program to the database manager. The operating system executes your coded trigger program to perform the actions you designed. The application waits until the trigger ends, and then gains control again. This might cause an application’s performance to degrade, because if the first trigger triggers other triggers (read it again, slower this time), it can take a while until the application regains control. (Note that I’m purposely not using the word “program.” This application can be on a web platform, a mobile platform, or any other platform application.) Even so, triggers excel at the following tasks:

• Enforcing business rules, no matter how complex—A good example is the aforementioned order-entry scenario. Suppose you want to ensure that whenever you enter an order in your database, the customer you are dealing with has no bad credit history. A trigger associated with the order master table can perform this check consistently and take the appropriate actions.
• Providing data validation and an audit trail—You might need to ensure that, whenever a salesperson enters an order, a representative is actually assigned to that particular customer. You also want to keep track of the violation attempts. Again, a trigger can be activated on the order master table to perform the validation and keep a log of the violators in a separate table.
• Preserving data consistency across different tables—In this case, triggers can complement the referential integrity and check constraints mentioned earlier in the this series, because they can provide a much wider and more powerful range of data validation and business actions to be performed when data changes in your database.

Triggers are important stepping stones on the path to modernization because they allow you to reuse code, implementing the old Java maxim write once, run everywhere. The fact that the trigger resides in the database and acts directly over the database tables, regardless of the application(s) that caused it to take action, frees you from writing two or more versions of the same code in different languages. Furthermore, if applications evolve or are replaced, your trigger will still work seamlessly, as long as the new/changed applications still perform the same operations over the database tables. In the end, you’ll have a single program to maintain (the trigger) that RPG, C, JAVA, C#, or other languages will “call” when they perform I/O operations over your tables. This allows you to move your entire front-end from green-screens to a web app, while keeping the backbone business logic on the IBM i, which is one of the many forms modernization can take.

Now that you’re probably convinced of the advantages of using triggers, I’ll show you how to create and maintain them…in the next TechTip. Just note that, because this series is dedicated to SQL, I’ll focus on the instructions SQL provides for creating, changing, and delete triggers—CREATE TRIGGER, ALTER TRIGGER, and DROP TRIGGER, respectively—but you can also create external triggers, written in a high-level language like RPG. It’s also possible to create and delete triggers with CL, using the ADDPFTRG and RMVPFTRG commands, respectively.