No, it’s not bitter and sweet or anything like that! INSERT is a very powerful SQL statement that many people don’t take full advantage of. I’m going to explain its two ways of working—its two “flavors” if you will. Keep reading!

Most programmers are familiar with the INSERT SQL statement, and some (including me) prefer it to Data File Utility (DFU) because it’s reproducible, controlled, and most important, easy to track. It’s true that you can save all those spool files produced by DFU somewhere, but it’s not easy to re-input data or even reuse inputted data. With INSERT, a simple copy-paste-adjust operation is all it takes to add a second or third record that shares some similarities with the original statement.

Vanilla INSERT: Plain, Simple, and Kind of Boring

You’re certainly familiar with the “insert one record with these values” INSERT statement, aka the Vanilla flavor—simple, unimaginative, easy. What you might not know is that there are some tweaks you can introduce into the most basic form of the INSERT statement.

Let’s say I want to add a course to the Courses table. There are two ways to do this: you can either specify which columns you’ll be providing values for and what those values are or simply specify a list of values. Here’s an example of creating a new course with the two alternatives, starting with the longer of the two:

INSERT INTO       UMADB_CHP2.PFCOM

(CONM, CODS, CODN, CODE , COTA, COSC)

VALUES(

'Advanced Trickery'

      , 'This course will help you take your trick-or-treat Halloween tricks to the next level!'

      , 'Manual Crafts'

      , 'The Joker'

      , 'Dennis the Menace'

      , '1'

)

;

Note that I’m providing values for all the columns. If I hadn’t, then the default value for the column (zero for numeric columns and '' for the character fields) would be used. I’ll show you later how this can be customized via Data Definition Language (DDL). However, because I’m providing all the necessary information, I can omit the column names this way:

INSERT INTO       UMADB_CHP2.PFCOM

VALUES(

'Advanced Trickery'

      , 'This course will help you take your trick-or-treat Halloween tricks to the next level!'

      , 'Manual Crafts'

      , 'The Joker'

      , 'Dennis the Menace'

      , '1'

)

;

Even though this second option is shorter (which makes it rather tempting to use), I favor the longer version for two reasons:

1. Clarity—The lists of column names and their matching values unambiguously state “what goes where” when the record is inserted. Also, you’re not bound to the order by which the columns appear in the table record. The columns might be alphabetically ordered, but you want to start your statement with the columns that form the record’s unique key and then fill in the rest of the data. With the shorter version, this is simply not possible because you have to stick to the order of columns imposed by the table definition.
2. Reusability—Even if new columns are added to the table, the longer INSERT statement will still work as expected, regardless of the position of the new columns in the table. With the shorter version, this might not be true, unless you always add the new columns after the last existing column of the record (which you should, by the way!). Note, however, that if the values for the new columns are not specified, they’ll be filled with the default value, which is not always a good option.

Strawberry (or Whatever Your Favorite Ice Cream Flavor Is) INSERT

My guess is that you’re used to the “vanilla” INSERT and use it regularly. However, there are situations, such as copying a group of records from one table to another, in which you fall back to the CPYF CL command. This command is nice and simple, but it falls short when you don’t want all the records from the original table to be copied to the destination table. Yes, you can use the FROMRCD/TORCD or FROMKEY/TOKEY keywords to limit the records being copied, but it’s still a bit cumbersome.

This second flavor of INSERT allows you to selectively copy records. The best part is that you can list the records you’ll be copying easily by using a SELECT statement. Interested? Let me explain how it works with an example.

The university managed to bring back from the dead a couple of rather reputed scholars to teach a summer course on physics: Max Planck and Albert Einstein. They need to be added to the Teachers table, which would typically be a manual insertion operation performed by the administrative staff. However, someone secured a copy of the relevant data and uploaded it to a temporary table named PFTEMP_TEM, which happens to have almost the exact same format as the Teachers table. It’s only missing the status column. Let’s see how you could copy its data to the Teachers table with an INSERT statement:

INSERT INTO UMADB_CHP2.PFTEM

SELECT      TMP.*, ‘1’

FROM       UMADB_CHP2.PFTEMP_TEM TMP

;

Notice the simplicity of the statement: With just a few lines, I copied all the data from one table to another and added the missing information. An INSERT with a nested SELECT statement is a powerful tool because the flexibility of the SELECT statement allows you to tailor the original data to the destination table by changing its format, translating information (for instance, it’s possible to translate a percentage to the respective letter grade, as you’ll see later in this series), and surgically selecting which records to copy. For instance, if PFTEMP_TEM had a different column arrangement (different number of columns or simply a different order), you’d just change the SELECT clause to match the destination table’s column order.

So, there you go: a new way to do inserts, which will rock your world (yes, that was a very indirect reference to the rocky road ice cream flavor)!