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.

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