We've now covered the most relevant aspects of SQL, providing practical and actionable information about SQL’s main topics. This article sums up the series to this point and contains links to the articles corresponding to the topics mentioned.

The database is so integrated into IBM i that you can program for years without having to explicitly use SQL. RPG provides native operation codes to manipulate data and uses “native” names for the data objects it handles. Therefore, an important first step is naming names—providing a list of SQL names and the corresponding RPG name:

• Library = schema or collection
• Physical file = table
• Non-keyed logical file = view
• Keyed logical file, access path, or index = index
• Record = row
• Field = column
• Field reference file = catalog

The next step involved explaining the data manipulation instructions that SQL offers:

• SELECT—For queries over native files (physical and logical) or SQL objects, such as tables and views, the SELECT instruction provides a simple yet powerful way to retrieve information from the database.
• INSERT—Adding records to a table is this SQL instruction’s purpose. You can insert a single record per statement by naming the columns and their respective values, or use a SELECT statement to read data from other sources and add the result of that query to a table.
• UPDATE— “Massaging” data with DFU can be a nightmare; the UPDATE SQL instruction makes that task much easier and more flexible. I used an UPDATE statement to explain another predicate—EXISTS—to demonstrate how you can update a column, taking into consideration information coming from another table.
• DELETE—SQL’s most dangerous statement after the DROP statement can act as sharply as a surgeon’s scalpel or as bluntly as Thor’s hammer; it all depends on the statement’s WHERE

I intentionally left out the MERGE instruction, because it can be confusing at first and it’s not crucial to proper DML. But don’t worry, I’ll get to it eventually!

The next few (okay, not so few) articles were about SQL column functions. These functions fall into two big categories:

• Aggregate functions—These functions take a set of values (like a column of data) and return a single (aggregated) value result from the set of values. A few of the aggregate functions discussed include AVG, COUNT, and SUM.
• Scalar functions—This group of functions acts over a value (a column or expression value) and allows you to simplify a series of tasks. I’ve discussed string functions such as ASCII, VARCHAR, LCASE, and TRIM, and date-related scalar functions, including TIMESTAMP, NOW, and DAYOFWEEK.

After a lengthy explanation about SQL statements and functions, I’ve talked about a few tools in which to practice your newly acquired SQL skills:

• Interactive SQL, a green-screen command line tool, similar to QCMD
• i Navigator’s Run SQL Scripts, a graphical, user-friendly, and functionality-laden tool
• a nice open-source, database-agnostic tool

Then came the fun part: taking SQL into your familiar territory. The next few articles discussed and demonstrated how to embed SQL statements in fixed format RPG using C/EXEC SQL, C+, and C/END-SQL to identify the start, continuation, and end of an embedded SQL statement, respectively. In free format RPG, this is a simpler affair because you just need to write EXEC SQL and terminate the statement, which can span as many lines as you want, with a semicolon character.

Embedded SQL gets even more useful when you get it to “talk” with RPG. This is achieved by the host variables, which are regular RPG variables, preceded by a colon character (:) when used in an embedded SQL statement. An RPG source file with embedded SQL requires a pre-compilation step to convert the SQL to something the RPG compiler can swallow, so a different compilation command is required. The CRTSQLRPGI command can be used to create modules, programs, or service programs. I recommend that you always create modules and then bind them to programs or service programs as needed. Some practical examples on the usefulness of embedded SQL followed, namely the Rtv_DayOfWeek and Chg_Case functions.

Still on the embedded SQL topic, cursors were discussed as a way to navigate row by row in the results of an embedded SQL SELECT statement. Both static and dynamic cursors (“empty shells” filled at run time by the PREPARE statement) were discussed, as well as a couple of ways in which they can be useful. Finally, a way to embed a few more DML statements was discussed.

Even after all of this SQL stuff, you’re still an RPG programmer, and the bulk of your source code is still written in RPG. However, encapsulating RPG code in stored procedures and user-defined functions allows you to open your RPG code to the outside world without having to rewrite it. The articles on this topic offered only a shallow explanation that is good enough for you to start, but further reading and experimentation is advisable.

No SQL introduction would be complete without at least a about the Data Definition Language (DDL). This is IBM’s bet for the future of file definition. DDS stopped evolving a few releases ago, while DDL continued to received regular (and numerous) new features. This subset of articles presented schemas, tables, views and indexes, which can replace the familiar library, physical, and logical file constructs.

The most recent set of articles talked about triggers. These are time- and sometimes life-saving “things” that you can use to empower your database with event-based, automated, application-independent actions that can be written in SQL or a high-level language. However, these articles only covered SQL triggers and discussed a few of their possible uses: enforcing business rules, triggering cascade changes in the database, and keeping audit information. All of this is done without writing a single line of RPG code! It’s important to mention that triggers are a very powerful tool. The explanation provided here is good enough for you to start using them, but in no way should it be considered a comprehensive tutorial on triggers. There are great, free books on that, such as the Stored Procedures, Triggers and User-Defined Functions in DB2 Universal Database for iSeries Redbook.

But don’t worry, this is not the end! I thought this would be a good time to look back and take stock of the road travelled thus far. There’s a lot more to talk about, so our journey will continue!