Nobody likes Open Query File operations. However, we’re all more or less forced to live with them and, more importantly, maintain them. Here’s how to replace them with SQL cursors.

The prospect of “killing” those error-prone, problem-magnet Open Query File operations sounds nice, doesn’t it? Well, SQL cursors are the way to go. However, before I get to that part, there are a few things about cursors that you need to take note of.

Before you learn how to use a cursor to replace an Open Query File, here are a few notes to keep in mind regarding cursors:

• The list of variables used by FETCH can be a data structure. This is particularly useful with cursors that have a long SELECT clause. You define a data structure with the appropriate variables and use it instead of the list after the INTO, like this:

Exec Sql FETCH mainCursor INTO :W_My_Data_Structure;

When I’m reading data from a single table, I sometimes define the record format of that table as an external data structure and use it in my FETCH operations.

• You can’t open a cursor that’s already opened or close a cursor that’s already closed. The system will return an error and stop execution.
• You can’t use FETCH on a closed cursor.
• The DECLARE statement must be specified before any other statements that mention the cursor in the source code. This is rather peculiar; it means that if you want to fetch data in source code line 200, the cursor must be defined before that line. I’ve always found this to be the source of many compilation errors, with very unfriendly error messages.

Never forget these tips! Some of them are basically common sense, but others are the product of countless hours looking for errors that weren’t actually there. It took quite a few programmers quite some time to distill this four-bullet-point list. Having said that, it’s finally time to tackle the real topic of this article!

Replacing the Dreaded OPNQRYF with an SQL Cursor

The Open Query File command or OPNQRYF, along with the GOTO and TAG operations codes, sits at the top of the RPG programmer’s worst nightmare list because what (eventually) started as a good, simple idea becomes a huge mess in no time. Then someone has to maintain that mess…and it’s never easy. However, it can get easier: just modernize the code when an opportunity presents itself. It’s going to take some time, but it’s time you’ll save in the future. With this in mind, I decided that it would be a good idea to show you how to get rid of OPNQRYF.

I’ve shown earlier in this series how to create a cursor using a basic SELECT statement. This statement is hardcoded in the DECLARE SQL statement and not changed by the other cursor-related operations. This might work in theory, but in real life, you probably want to refine the record selection at run time. This is usually achieved by an OPNQRYF command executed prior to the program call. Big QRYSLT values are common, leading to nightmarish commands that don’t always perform as you’d wish. A static, hardcoded cursor doesn’t solve the problem; you need a dynamically definable data access (or cursor), like you had (or still have) with OPNQRYF.

The solution is defining a flexible cursor using host variables in the DECLARE statement. Let’s say I want to refine mainCursor from the previous TechTip’s example; I want to be able to indicate the warehouse ID dynamically. The new DECLARE statement looks like this:

/Free

   Exec SQL

     DECLARE mainCursor CURSOR

     FOR

     SELECT InvMst.ItemID, ItemDesc, ExpDate

     FROM   InvMst InvMst

     INNER JOIN ItmMst ItmMst ON InvMst.ItemID = ItmMst.ItemID

     WHERE WHID = :K_WHID;

Notice the line in bold? I’ve added a WHERE clause with a host variable. This variable’s value is not known when the cursor is declared, but that’s not a problem, because the DECLARE statement is more concerned with the SELECT clause—it needs to know which columns are going to be part of the temporary result table it creates. K_WHID matters when the FETCH statement is executed; that’s when K_WHID’s value will be used to replace the host variable name in the statement.

Creating a replacement for an OPQRYF is feasible, assuming that you understand what’s in the QRYSLT part of OPQRYF. It can be as easy as “translating” the QRYSLT code to the appropriate SQL comparisons and putting them in the WHERE clause of the DECLARE statement.

SQL’s power allows one additional step toward flexible data access: you can create a dynamic SELECT statement for your cursor declaration! In other words, you can build the DECLARE’s SELECT statement conditions (columns to return, selection, aggregation, order, and everything else) at run time. Sounds even better, doesn’t it? Well, you’ll have to wait for the next TechTip to learn how to do it!