It's usually easy to change or delete a couple of records with DFU, but updating/deleting large sets of data, particularly if you're changing the same field value in the entire set, is tedious. SQL's Update and Delete statements make these tasks simple and quick.

So far, this series has shown you how to build a query with one or more files and how to add data to tables. This time, I'll discuss how you can use two DML instructions to replace the dreaded Data File Utility (DFU). Let's start with Update and then move on to Delete.

"Massaging" Data with Update

Usually, we use (or at least we should use) programs to change data: they enforce a series of conditions, business rules, and other validations to ensure that the changes are correctly implemented. However, at one point or another, we all used the DFU to "massage" some data into its appropriate state. Surely you know how boring and time-consuming it is to change a dozen records or more using DFU. Instead of the Data File Utility (known in some shops by other colorful names, which I won't repeat here; use your imagination!), you can use the Update SQL instruction. Its syntax is somewhat similar to the Select instruction. Actually, I usually write a Select statement just to check whether my field names and conditions are correct and then transform it into an Update statement. Here's Update's syntax:

UPDATE      <table>

SET         <column 1 = new value 1>

            [, column 2 = new value 2, …. column n = new value n]

[WHERE      <list of conditions>]

The WHERE clause is optional, even though it's extremely dangerous to perform an Update without it! You'll change the fields mentioned in the SET clause in the entire table (yes, Update is the SQL's equivalent to Thor's Mjölnir hammer; you must be worthy to wield it and use it with great care). You can update as many fields as you'd like, and the <new value> can be another field, an expression, or a literal. Note that you can only update fields in one table at a time.

So, if I wanted to change all the items with the 'A123' ID that are in warehouse 333 to the shelf 77 in the inventory master table I've been using for my examples in this series, I'd write the following Update statement:

UPDATE      InvMst

SET         ShelfID = 77

WHERE             ItemID = 'A123'

AND WHID = 333

Note that if a unique key (an Index in SQL lingo) were defined over the table InvMst as a keyed logical file that included the ItemID, WHID, and ShelfID columns, this Update operation would fail, because all updates must conform with the target table's unique constraints and indexes. The same is applicable to check constraints (validation rules defined for a column) and primary keys. My InvMst table is a DDS-defined table (OK, let's call it by its proper name: physical file), so it doesn't have check constraints, but it can have unique keys that can cause the update operation to fail. I'll discuss the constraints in more depth in later in this series, when I explain a bit about data definition in SQL.

At first sight, it may seem that you can't use more than one table in an Update statement; it's true that you can update only one table at a time, but there are ways to use a second table to help decide which rows should be updated. Here's an example, again from my imaginary inventory scenario: let's say that I have a Warehouse Shelf Master table or ShlfMst, which has the warehouse and shelf IDs as primary keys and contains status (ShelfSts) and location (ShelfLoc) columns, among others. If I get a list from the Warehouse Maintenance Department containing the shelves that are going to be unavailable because a maintenance operation is going to take place, I can write a statement that updates the Shelves table based on the list provided by the Warehouse Maintenance Department. I could try to establish a relation between the tables using the IN predicate, but it wouldn't be 100 percent accurate because my primary key has two columns. I'll use the EXISTS predicate instead:

Exec Sql

UPDATE ShlfMst Shl

SET ShelfSts = 'U'

WHERE EXISTS    ( SELECT    *

FROM MaintenanceList ML

WHERE     Shl.WHID = ML.WHID

AND Shl.ShelfID = ML.ShelfID

);

So, what's going on here? I'm doing an implicit Inner Join between the Shelves and MaintenanceList tables using the warehouse and shelf IDs. If you're not familiar with the Inner Join concept, please read the article about it. What EXISTS is doing here is selecting for update the rows from the ShlfMst table that match those in MaintenanceList with the WHID/ShelfID key. Then I'm updating the ShelfSts column with an unavailability flag ('U'). The indenting is not mandatory, but it improves the general readability of the statement.

One final tip about the Update instruction: I usually perform a Select with all the column names and conditions that I want to use in my Update statement, and then I do the following:

1. Move the FROM <table> to the top of the statement and replace FROM with UPDATE.
2. Replace SELECT with SET.
3. Use the SELECT list of columns to create my SET clause.
4. Insert the equal sign (=) and the new value for each column.
5. Replace the AND/OR operator with a comma.
6. Double-check my WHERE clause before executing the statement…just in case.

Try Not to Do (Too Much) Damage with Delete

If doing updates via DFU is time-consuming, deleting records—pressing F23 consecutively to delete a record and, sooner or later, deleting the wrong record—is even worse. SQL's Delete instruction helps you delete only the records that you want to delete, or at least those you instructed the database to delete. The Delete instruction is very simple:

DELETE FROM       <table>

[WHERE            <list of conditions>]

Even though the WHERE clause is optional, neglecting to mention it will delete all the rows in <table>, so unless that's really what you want (I'm talking about the SQL equivalent to the CLRPFM CL command here) always double-check before executing the instruction or, better yet, write a Select statement first and transform it into a Delete statement. Unless you initiated a transaction that you can roll back, the changes to the database are permanent. Here's an example: deleting a row from my InvMst table; this is quite straightforward.

Let's say I want to delete the rows that don't have a Shelf ID, regardless of every other attribute. I'd simply write this:

DELETE FROM       InvMst

WHERE       ShelfID = 0

Just like Update, a few rules apply to Delete that might cause the instruction to end in error—for example, if you're trying to delete rows without proper authorization, if there are referential constraints in place that prevent the deletion, or (this is so obvious that I shouldn't even mention it) if a row with the conditions specified in the WHERE clause doesn't exist. You can also delete rows from a table using another table; you just need to use the EXISTS predicate, like I've shown for Update.

Goodbye, DFU. Hello, Update and Delete.

Now that you know a bit more about the Update and Delete statements, you can finally get rid of DFU. Be sure to practice with a few updates and deletes over test tables before going for the real thing. I cannot repeat too often that Update and Delete are very powerful tools: you can do some serious damage with them, so create your own checklist (or use mine) before pressing the final ENTER on an Update or Delete statement.

Column Functions Coming Up!

The next few articles will discuss some of the column functions SQL provides and how they can make your life easier, starting with the aggregate functions.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale

Also Read

SQL 101: DDL Recap—Improving Our Basic SQL Tables, Part 2

TechTip: Automate Complex Tasks Using SQL and User-Defined Table Functions

SQL 101: DDL Recap—Improving Our Basic SQL Tables, Part 1