Ready for more tips on STRSQL? Even if you’re familiar with this old and venerable tool, this article might show you something new.

The previous article started to discuss STRSQL and stopped short of explaining a very important set of features. So I’ll just pick up where I left off: I’m going to explain what Option 1 of the Interactive SQL Session Services screen, reachable by pressing F13 on the main screen, can be used for. This option brings up the Session Attributes screen, depicted in Figure 1.

Figure 1: The Change Session Attributes Screen

In this screen, the most relevant options are the following:

• Statement processing—Set to *RUN by default, this option also allows you to validate the statement without running it, with option *VLD. If you use *SYN, the database engine will check the statement’s syntax, according to DB2 Universal Database for i5/OS syntax rules. A syntax check verifies that the statement is constructed according to the SQL rules for that statement and its parameters. If the statement refers to columns, a validity check verifies that all statement elements referred to (schema, table, view, column, library, file, or field) actually exist.
• SELECT output—This is probably the most flexible option, because it allows you to redirect the output to the printer by typing a 2 or, much more interesting, redirect the output to a database file. Why is this interesting? It can save you a lot of time. Instead of creating really long and complex multi-table SELECT statements, you can start with the largest table, run a SELECT statement over it (having redirected the output to a file beforehand), and then use that smaller, more manageable table to continue drilling down in your tables. Repeat this “change file name, then run a new SELECT” process until you get to the final result.
• Naming convention—In the native naming convention you’re used to, represented here by the *SYS option, a slash character (/) is used to separate the library from the file name. However, this is not standard SQL; SQL’s cross-platform notation uses a period character (.) as a separator. If you want to use this notation, change this session attribute to *SQL instead. As you’ll see later, one of the other SQL tools available also requires this notation.

I intentionally left out the Commitment Control attribute because that’s something I won’t talk about in this series. It’s not a complicated feature, but it makes more sense to learn about it when you have a little more experience with SQL. (It’s best to be patient and not try to learn everything at once so you don’t get overwhelmed or frustrated.)

When you type a valid SELECT statement and press Enter to execute it, the results screen is shown, assuming that you didn’t change the “SELECT output” attribute default value. In this screen, you can use the usual PageUp and PageDown keys to navigate, but you can also take advantage of the Position to line and Shift to column fields at the top row to jump around. For instance, typing “+ 100” in the Position to line field and pressing Enter will take you down 100 lines in the result list, assuming you have more than 100 lines of results. Similarly, typing “+ 10” in the Shift to column field will take you 10 columns to the right in the results. In both fields, using the minus sign (-) followed by a number will have the opposite effect of using plus (+). It’s also possible to type a number in these fields. For instance, typing “50” in the Position to line field and pressing Enter sends you to the 50th line of the results.

You can also use F19 to move to the left and F20 to move to the right instead the Shift to column field. If the result lines don’t fit on the screen, which will certainly happen when you work with long character columns or a long SELECT clause composed of a lot of columns and/or expressions, you can use F21 to “freeze panes” similar to what you’d find in MS Excel. F3 or F12 will send you back to the SQL command line. Once you’re done experimenting with STRSQL, use F3 to exit, making sure you select the appropriate exit option for the session history, as shown in Figure 2. As I said before, saving your history might spare you the time you’d waste retyping those awfully long statements you’ll surely write at one point or another.

Figure 2: The Interactive SQL Exit Screen

STRSQL is a nice tool and it will do for the daily tasks, but the restrictions imposed by the green-screen environment limit your efficiency in more complex tasks, such as creating tables or triggers. The next tool on my list, i Navigator’s Run SQL Scripts tool, will be of great help once you get the hang of it.

That’s all for the STRSQL discussion, so feel free to add to it by sharing your own tips and experience in the Comments sections below.