It’s time to get to know the newest version of the Run SQL Scripts tool, part of the Access Client Solutions package. Even if you already use it, you might learn something new.

Assuming that you read the previous TechTip or already had IBM i Access Client Solutions (ACS) installed, you should be ready to learn more about the new Run SQL Scripts tool. It seems that IBM listened to its customers, took a few hints from the competition, and introduced some really neat features into this new tool. Let’s explore it together.

This will be a very hands-on TechTip, so fire up the ACS launcher, pick a System connection from the respective combo box, and click on the “Run SQL Scripts” option. You’ll be greeted with a new window, rather similar to the iNavigator’s Run SQL Scripts window. But don’t let looks fool you; this new tool has a lot more to offer. Let’s start by typing a simple SELECT statement:

select * from sysibm.sysdummy1;

You’ll notice that the select and from reserved words are presented in a different color. This is a nice touch, which competing tools (including some from IBM) already had for quite some time.

Now let’s run the statement; this can be achieved via the Run menu, just like before, but you can also enable the option to “run statement on double-click,” the first option of the Options menu, to speed up the process. This menu now has a couple of new options, which I’ll explain in a minute, and it’s tidier, with a clever separation of the options into logical groups. The new options are related to the execution of the statements, and they’re pretty much self-explanatory: “Highlight Next Statement After ‘Run Selected’” and “Hide Results on ‘Run All’ or ‘Run from Selected’.”. Again, this type of thing already existed on the competing tools, and IBM was lagging behind.

Now let’s examine one of the new features introduced in this version, which I personally find quite useful: the SQL formatter. Start by typing the statement below, exactly as it is written:

SELECT TYPE_NAME, DATA_TYPE FROM SYSIBM.SYSTYPINFO;

Now select the entire statement and press Ctrl+Shift+F or go to the Edit menu and select SQL Formatter > Format Selected. You’ll see that your statement remains the same, in terms of content, but its formatting changed a bit. I’ve been playing around with the definitions a bit, so you might get a different result, but this was what I got:

select TYPE_NAME, DATA_TYPE

    from SYSIBM.SYSTYPINFO;

Neat, isn’t it? Here’s how to set it up according to your preferences: go to the Edit menu again, select SQL Formatter and then the Configure option. You’ll see something similar to Figure 1.

Figure 1: The SQL Formatter Settings window

Here you can choose how the reserved SQL words (first line) and identifiers (second line) are formatted. I know people who like their Selects, Updates, Deletes, and so on in uppercase and others who argue that they’re used having the opposite. Instead of forcing a formatting choice upon us, IBM wisely chose to leave it to the user to select the best fit.

Next is the maximum line length; this option line causes the code to break to a new line whenever it’s longer than whichever value is set on the respective box. I think the default value is 100, but you can set it to anything between 0 and 2,147,483,647.

Then comes the indent value, very useful in long and complex statements. The default is 4, but again you can set a value between 0 and 24.

For me, the most interesting (and useful) part is what comes next: when to automatically break to a new line, based on the statement’s contents. Here’s how it works: If you want the statement to “jump” to a new line each time the formatter finds a comma, just change the “new line on comma” option to “new line before” or “new line after.” Personally, I prefer “new line before,” even though the formatter “eats” the space between the comma and the column/variable name, which is not very friendly. The formatter can perform a similar action when it finds an AND or OR. I particularly like this feature to properly indent and make clearer long JOIN statements. Finally, there’s also the same type of thing specifically for the CASE keyword, but you’re not allow to play around with it; you can either enable or disable it and nothing more.

I’ll have to stop here, but feel free to continue to explore this great new tool.

The next TechTip will continue to explain Run SQL Scripts’ new features and a few tricks I’ve picked up along the way.