They say a picture is worth a thousand words. I say that, sometimes, a single DELETE SQL statement is worth a thousand lines of RPG code. Let me show you how…and why.

You’ve been reading on and on about embedded SQL for quite a few articles now (sorry about that) without a word about INSERT, UPDATE, or DELETE. Don’t think for a minute that you can only embed SELECT statements in your RPG! You can issue INSERT, UPDATE, and DELETE commands from your code as easily as you use SELECT. However, RPG and SQL don’t play nice when it comes to changing data in the same file within the same program. If you want to update a bunch of records in a file that you’re also using in the program, the file must be closed before you issue the UPDATE statement.

The problem is that RPG immediately opens the files in the F-specs as soon as execution starts—unless the file has the UsrOpn keyword. This is what you need to do in the files that you’ll manipulate in both RPG and SQL code: define them with UsrOpn and make sure they’re closed before you issue an SQL statement over them.

Having said that, we’re ready to begin! Let’s start with INSERT. You can perform an INSERT as easily as you do a SELECT; for instance, the following statement inserts a new row in the InvMst table:

Exec SQL

   INSERT INTO   INVMST

   (ITEMID, LOTNBR, EXPDATE, WHID, SHELFID, ITEMUN, ITEMQTY)

   VALUES('A123', 1, Date('2015-12-31'), 24, 12, 'KG', 100);

You can also specify host variables, mixing them with literal expressions and SQL functions:

Exec SQL

   INSERT INTO INVMST

   (ITEMID, LOTNBR, EXPDATE, WHID, SHELFID, ITEMUN, ITEMQTY)

   VALUES(:W_ItemID, :W_LotNbr, CurDate, :W_WHID, 12, 'KG', 100);

Although this is possible, it might not be very practical because you can also assign a value to each of the row’s columns (or record’s fields, in RPG lingo) and issue an RPG WRITE operation. This might make sense if you’re doing it in a loop or with data from a SELECT statement—remember INSERT’s alternative syntax? If not, go back to this article and review it.

SQL’s embedded INSERT might not represent a huge advantage over RPG’s native WRITE, but DELETE is a whole different story. RPG’s DELETE operation code erases a single row at a time, but SQL’s DELETE can erase as many as you want (or don’t want, if your WHERE clause is not correct). So, there’s an obvious advantage in using SQL’s DELETE; let’s see how:

Exec SQL

   DELETE FROM   INVMST

   WHERE         ItemID = :W_ItemID

                  AND ShelfID = :W_ShelfID;

The same could be said for SQL’s UPDATE and its RPG counterpart. Here’s a simple embedded UPDATE statement:

Exec SQL

   UPDATE  INVMST

   SET           ShelfID = :W_ShelfID

   WHERE   ItemID = :W_ItemID

            AND ExpDate < CurDate + 3 MONTHS;

This moves all the items with the item ID stored in RPG’s W_ItemID variable that will expire in three months or less to the shelf ID stored in RPG’s W_ShelfID variable.

These are partially static data manipulation statements. I’m able to specify host variables in some places, but most of the statement is hardcoded. While this is not a big issue in the DELETE statements (okay, you might want to add or remove a condition in the WHERE clause, but that’s it), the UPDATE statements need to be more dynamic. How do you do it? Simple—just use a PREPARE statement to create the SQL. Yes, the PREPARE statement from a previous TechTip.

If I want to issue a dynamic UPDATE, I just need to follow three simple steps:

1. Write the UPDATE statement, using regular RPG variables and string operations.
2. Issue a PREPARE SQL statement that turns my string into an SQL prepared statement.
3. Execute the prepared statement with the EXECUTE SQL instruction.

Sounds simple, doesn’t it? It really is! Let’s look at an example:

   W_Stmt = ‘UPDATE ‘ + %Trim(W_File_Name)

           + ‘ SET ‘ + %Trim(W_Field1_Name) + ‘ = ‘

           + W_Field1_Value;

   Exec SQL

       PREPARE S1 FROM :W_Stmt;

   Exec SQL

     EXECUTE S1;

This will dynamically set a field whose name is in W_Field1_Name with the value contained in W_Field1_Value, for a certain file, whose name resides in W_File_Name. Note that I can specify additional fields, or a WHERE clause—a comprehensive UPDATE statement, in short. Also note that in this simplistic example, I’m not checking SQLCOD’s value after each SQL statement. Remember, however, that embedded SQL errors are usually silent, so it’s a good idea to check for errors after issuing an SQL statement with a simple statement like this:

IF SQLCOD = 0;

If SQLCOD is not zero, then something went wrong and you should act accordingly. This is an interesting tool for debugging, particularly when you’re starting out with embedded statements, because the contents of SQLCOD are actual SQL status codes (or errors) that you can look up on the documentation or online.

Coming Up

Now that you know a thing or two about SQL and have seen how you can use SQL in your RPG code, it’s time to learn how you can use RPG in SQL, thus making your RPG code available to the “outside world.” That’ll be the topic of the next TechTip!

In the meantime, feel free to comment, correct, or suggest stuff about this TechTip or this series, via the Comments section below or in the usual LinkedIn groups where my articles pop up.