Today’s TechTip is a two-for-one. I’ll talk about SQL’s OVRDBF replacement, ALIAS, and a simple yet dangerous SQL statement, DROP. Keep reading to find out more.

Let’s start with ALIAS. In a nutshell, we can say that ALIAS is Override Database File (OVRDBF) made simple, practical, and permanent.

If you ever used the OVRDBF CL command, then the functionality provided by ALIAS should be easy to grasp; it’s exactly the same! If you never used OVRDBF, it’s a way to use an alternate name for a file or, most importantly, a member of a file. This is especially important because you can’t specify a file member in SQL. The file member concept is an IBM i peculiarity, and SQL has no idea how to handle it. Fortunately, the CREATE ALIAS SQL instruction allows you to create a name for a given member of a file.

Its syntax is quite simple:

CREATE ALIAS <schema/library name>.<alias name>

FOR <schema/library name>.<file name>(<member name>)

Note that you can create an alias for a file member in a separate library—or schema—of the original file location. In my opinion, this might create some confusion, so I prefer to avoid it whenever possible.

Suppose, for example, that I want to query a physical file named Inv_Log, which keeps monthly logs of my inventory positions, a kind of monthly snapshot of the stock. The problem is that each “snapshot” is saved in a separate member within the file, following an L_<year>_<month> pattern name. For instance, the member for January 2021 is called L_2021_01. If I want to query this particular member, I need to create an alias first:

CREATE ALIAS MYSCHEMA.INV_LOG_2021_01 FOR MYSCHEMA.INV_LOG (L_2021_01)

After issuing this statement, I can treat INV_LOG_2015_01 as a regular table or view, mentioning it in DML statements, thus allowing me to query a file member directly. Naturally, you can also use CREATE ALIAS to shorten (or lengthen) the name of a table or view. The only difference in the command to issue is the final part—the “(<member name>)”—which is not applicable. For instance, if you want to create an alias for the MYSCHEMA.PF12345 file that clarifies what it stores (let’s say it’s configuration data), you can simply issue the following command:

CREATE ALIAS MYSCHEMA.TABLE_CFGDATA FOR MYSCHEMA.PF12345

Note that, unlike OVRDBF, aliases are permanent. If you want to get rid of them, you’ll need to issue a DROP ALIAS statement, which is part of the family of commands I’ll talk about next.

SQL’s Way to Delete Things: Drop Them

DROP is actually a set (or family) of commands, just like the CREATE commands I talked about a few TechTips ago. For each CREATE <something> command, there’s a DROP <something> counterpart. That’s how you remove or delete SQL “things.” You probably noticed that the DELETE SQL statement is nothing like the CL DLT* commands, right? You also might have noticed that the way to remove a constraint from a table involves the word “drop.” In SQL, DROP is used to remove or delete stuff: DROP ALIAS, DROP INDEX, DROP VIEW, DROP TABLE, and DROP SCHEMA do exactly what they appear to do—delete stuff. Their syntax is also pretty straightforward. Here’s how to remove the alias created earlier in this article:

DROP ALIAS MYSCHEMA.INV_LOG_2021_01

Note that some DROP statements might not work due to referential constraints (such as table dependencies) or other details (a table is in use or was not found, for example). In general, however, think twice before issuing a DROP statement. If the idea is recreating a SQL “thing,” check whether you can use an ALTER statement instead. Note that even though an ALTER VIEW statement doesn’t exist, you can issue a CREATE OR REPLACE VIEW, which in practice does the respective DROP/CREATE operations for you, if the view already exists.

If you really mean to remove permanently, consider the side effects that the operation might have. For instance, dropping an index (explained in the previous TechTip) can have unexpected impacts on performance because a view or an embedded SQL statement might be implicitly using it.

That’s all I have for now! Next time around, I’ll introduce you to your new best friend: the SQL trigger. Until then, feel free to comment, correct, or share your experience in the Comments section below.