Now that you know how to create simple triggers from our previous article, Introducing Database Triggers, let’s move on to more complex scenarios.

By Rafael Victória-Pereira

As you probably realized by now, a trigger can be used for many different tasks. Updating a certain value each time a record is somehow created or changed is just a very small part of what you can do with a trigger. Let me take you on an exploration of a few scenarios where a properly crafted trigger can be a simple solution to a complex problem. Instead of vague and insipid scenarios, we’ll return to our fictional UMADB database and its environment to provide something you can actually relate to. So, just to quickly get you back “into character”: we work for ACME University’s IT department, and we’ve been overhauling the database in order to open it to all the non-IBM i applications that need its data.

Python has a bunch of built-in functions, and it also comes with a whole list of modules and classes that can be used to construct your programs. I introduce programming in Python here. In most cases, you will start by building functions, and those functions may, or may not, be combined into modules at some point. We’ll take it a step at a time.

By Pete Helgren

Editor's Note: This article is excerpted from chapter 9 of Open Source Starter Guide for IBM i Developers, by Pete Helgren.

Functions

For RPG programmers, at least the more “modern” ones (whoever they are), monolithic code is an anathema. It’s hard to read, hard to debug, and hard to share. And if you do decide to share or copy it, then if you tweak the “mother” of the others, you need to update the others as well. Most RPG and COBOL programmers I know abandoned that technique about the time that Prince changed his name to ... well, whatever it was changed to. What replaced the monolithic coding style? Well, subroutines were the first step, and…