Now that you know how to create a table, a proper SQL table, let’s see how you can change it without having to re-create it! Yes, it’s possible. Keep reading to find out more.

In the previous TechTips, I’ve created the inventory, item, and warehouse master tables. However, the relationship between these tables is not yet enforced at database level. I know, you’re used to doing this using an RPG program. However, just as in the case of the timestamp that is automatically updated by the database engine, there’s also a way to define, at table level, that the value of a certain column must be cross-checked with another table’s column. In other words, I can only use item IDs in the inventory master table that have been previously defined in the item master table. This is what’s called a foreign key. You probably have a lot of these situations in your applications—and you’re probably handling the cross-checking using RPG. Well, SQL can take care of that for you, with its equivalent to the CHGPF CL command: ALTER TABLE. You can use this SQL instruction to add or remove (drop, in SQL lingo) columns, constraints, and primary keys, among other things.

The ALTER TABLE command has the following syntax:

ALTER TABLE <Schema or library name>.<table name>

     ADD COLUMN <column name> <column definition>

         [BEFORE <existing column name>]

     ALTER COLUMN <column name> <new column definition>

     DROP COLUMN <column name>

     ADD|DROP CONSTRAINT <constraint name> <constraint type>

There’s more to ALTER TABLE’s syntax, but for now this is enough. (You can have a look at the DB2 for i Reference manual for all the nitty-gritty details.) The first part of the syntax should be straightforward:

ALTER TABLE <Schema or library name>.<table name>

This identifies the table I want to change. Then come the changes I want to perform. I’m only mentioning columns and constraints because that should suffice in most cases, but there’s a lot more you can do with this SQL instruction.

Adding a column is simple: I just specify the column’s name, data type, length, and constraints (such as PRIMARY KEY or UNIQUE). I can even add a column somewhere between the existing columns, by indicating the existing column’s name in the optional part of the statement:

[BEFORE <existing column name>]

Easy as pie! The same goes for the column change operation: Just type ALTER COLUMN, followed by the column’s name and new definitions. Removing a column from the table is even simpler, because you just need to type DROP COLUMN followed by the column’s name.

Adding and removing constraints is also easy, but the constraints are checked upon creation (remember the ItemID constraint issue from a previous example, from the last TechTip?), and each type of constraint has its own syntax. I’m going to add a foreign key constraint next, so let’s review its syntax:

ADD CONSTRAINT <constraint name> FOREIGN KEY (<current table’s column name>)

REFERENCES <dependant schema or library name>.<dependant table name> (<name of the column in the dependant table>)

It’s easier than it looks. Let’s add a foreign key to the inventory master table so that any value added or changed for the ItemID column is cross-checked with the item master table. If a match is not found, the insert/update operation fails. Here’s what the statement looks like:

ALTER TABLE MYSCHEMA.INVMST

     ADD CONSTRAINT FK_ITEMID FOREIGN KEY (ITEMID)

         REFERENCES MYSCHEMA.TBL_ITEM_MASTER (ITEMID)

If you’ve been entering these SQL statements in your own environment, you’ll get an error after this one. Why? Well, I inserted a row in InvMst in a previous TechTip, to demonstrate the Last_Changed column functionality, and this row’s ItemID doesn’t exist in the table (actually, the table is empty). The database engine went looking and found that it couldn’t apply the change requested. I’ll need to delete that row from InvMst before trying again, so let’s issue a Delete All Rows From Inventory Master statement, similar to a CLRPFM CL command:

DELETE FROM MYSCHEMA.TBL_INVENTORY_MASTER

This clears the table so it’s now possible to add the foreign key constraint. If you’re using Interactive SQL, pressing F9 a couple of times should bring back the ALTER TABLE statement. Execute it again, and this time it should work.

But wait! The inventory master table has three foreign keys: ItemID, WHID, and ShelfID. I haven’t, quite on purpose, supplied the warehouse shelf master table definition, so try to write it yourself. I’ll help a bit: This table has six columns: The warehouse ID, and shelf ID form the table’s primary key, and then the shelf’s dimensions (height, width, and depth) are in three separate columns, and the final column is a 120-character column for any comments regarding the shelf. Give it a try; if you can’t figure it out, I’ll provide the answer in the next TechTip.

Now, let’s get back to InvMst’s foreign keys. I was saying that this table has three foreign keys; you’d think that you’d have to issue three ALTER TABLE statements to add them, right? Well, you can actually write just one statement with several ADD and/or DROP actions. First, though, let’s drop (remove) the constraint added previously:

ALTER TABLE MYSCHEMA.INVMST

     DROP CONSTRAINT FK_ITEMID

Now let’s add the constraints in a single statement:

ALTER TABLE MYSCHEMA.INVMST

     ADD CONSTRAINT FK_ITMMST_ITEMID FOREIGN KEY(ITEM_ID)

         REFERENCES MYSCHEMA.TBL_ITEM_MASTER (ITEM_ID)

     ADD CONSTRAINT FK_WHMST_WHID FOREIGN KEY (WHID)

         REFERENCES MYSCHEMA.TBL_WAREHOUSE_MASTER (WHID)

     ADD CONSTRAINT FK_SHLFMST_WHID FOREIGN KEY (WHID)

         REFERENCES MYSCHEMA.TBL_WAREHOUSE_SHELF_MASTER (WHID)

     ADD CONSTRAINT FK_SHLFMST_SHELFID FOREIGN KEY(SHELF_ID)

         REFERENCES MYSCHEMA.TBL_WAREHOUSE_SHELF_MASTER (SHELF_ID)

Note that the link between the inventory master and warehouse master tables has two columns: WHID and SHELF_ID. That’s why you see two constraints for the WHID column, pointing to different tables.

This was a brief overview of all the things you can do with the ALTER TABLE SQL instruction. There’s much more you can do! Make sure to read the documentation about it and experiment with your own tables and scenarios. Feel free to use the Comments section below to share your findings, doubts, and thoughts on this topic.

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