It's one thing to create a great SQL query; it's another thing entirely to let your users do it dynamically.

SQL is not a difficult syntax; it was designed to be relatively easy to use even for non-programmers, and it lives up to that goal. Selecting and sorting data is pretty straightforward: the WHERE clause and the ORDER BY do the heavy lifting. The harder part comes when the user wants to select a specific part number or a date range or a list of states or a combination of those or none at all. In this article, I'll show you the brute force method and then something a little more elegant and better-performing to boot!

Setting the Table

I've been doing a lot of inventory work lately, so let's take a look at a hypothetical item master file. Obviously, master files have dozens of fields, but for this example, I just need a few simple fields.

The name of the file is ITMMST, and every field is prefixed with IM. I like to do things that way. Field naming is not quite so much of an art as it was back in the days of six-character field names, but consistency is still important. I can write a whole article just on naming conventions, but that's not the point of today's exercise.

Instead, just look at the fields. I've got an item number, the primary vendor, and the ABC code. Assume all fields are alphanumeric.

What we want is to be able to let the user enter selection criteria:

1. Enter a primary vendor number or blank for all.
2. Enter up to three values for ABC code or blanks for all.

The basic statement would be something like this:

  exec SQL declare Items cursor for

    select IMITEM from ITMMAS

      where IMVENDOR = :pVendor

        and IMABC in (:pABC1, :pABC2, :pABC3);

Not much to it. However, this handles only the cases in which the user specifies selection values for each of the categories. It doesn't help much if the user wants a list of all items from a specific vendor, regardless of the ABC code. We'll need something a little more complex for that.

Using the Big Hammer of Dynamic SQL

Perhaps the simplest way to handle this sort of thing is to use the brute force method of creating a statement with SQL. Dynamic SQL actually comprises two different techniques, one with parameters and one without. Creating the statement without parameters is perhaps the easiest. I would build my SELECT statement as a varying string:

  selectSQL = 'select IMITEM from ITMMAS';

  noClauses = *on;

  if (pVendor <> *blank);

    if noClauses;            

      selectSQL += ' where';

    else;

      selectSQL += ' and';

    endif;

    selectSQL += (' IMVENDOR = ' + QT + pVendor + QT);

    noClauses = *off;

  endif;

The first two lines create the SELECT statement without any selection criteria. The next section is the specific code for the vendor number. If a vendor is specified (the field is not blank), the code adds a new clause. The logic first checks to see if any clauses have been added yet. If not, it appends a WHERE; otherwise, it appends AND. I can then clone this code for each selectable field.

Note that there is a logical inconsistency in this particular snippet: there is no way the field noClauses could be true at this point, so really I don't need the check and I could always force a WHERE. But this only works for the very first comparison; once I add additional fields, the "if noClauses" test becomes very important. Also, note the use of the named constant QT. This field is initialized to a single quote.

With dynamic SQL, you have to use the PREPARE statement. Rather than just declaring the cursor, you first prepare the statement and then declare the cursor using the prepared statement. This has a lot of overhead, especially compared to static SQL, which I'll cover in the next section.

  exec sql prepare selectStatement from :selectSQL;  

  exec sql declare c1 cursor for selectStatement;    

A different dynamic technique involves the use of parameter markers. I haven't decided whether I like or dislike parameter markers. Because they force you to know most of the statement beforehand, they seem to be almost the worst of both worlds: less flexible than a dynamic statement without parameters but more overhead than static SQL.

Making Static Sing

OK, not perhaps the most graceful metaphor, but the point is still valid: static SQL really sings. That's because static SQL statements get more completely compiled, meaning they should execute better than their dynamic counterparts. As usual, your mileage may vary, particularly when it comes to SQL, but generally speaking, a static SQL statement will be the better performer.

However, the hard part is figuring out how to handle the generic values. For example, how do we tell the SQL that a blank vendor number means to select all vendors? Let's take the basic WHERE clause:

  where IMVENDOR = :pVendor

This will work when the user enters a vendor, but if the user leaves the field blank, no vendors will be selected. So we add a second condition to handle the possibility of a blank vendor code:

  where (IMVENDOR = :pVendor or :pVendor = ' ')

Now the record will be selected if the pVendor field is blank or if it matches the IMVENDOR field on the record. The only thing is to be sure that your "select all" value is not actually a valid value for the field. In this case, a blank value might be valid for the IMVENDOR field (for example, if the item is not purchased). In that case, you would need to use a different select all value, such as an asterisk.

Another case is when you want to allow multiple valid values. A few variations on the theme exist, but generally speaking, you can either use the IN keyword or create multiple clauses like the one above and "or" them together. Let me show you the former:

  where IMABC in (:pABC1, :pABC2, :pABC3)

This is simple enough. The user is prompted for three ABC values:

  Enter ABC codes: _ _ _

Users can enter the values they want to select in the three slots, leaving unused slots blank. The WHERE clause will then select only those that match the valid values entered. For example, to choose only ABC codes A and B, the user can enter A and B and leave the third slot blank:

  Enter ABC codes: A B  

Thus, the WHERE clause would check to see if the ABC code was in the list of values A, B, and blank. Since no records have blank, only A and B records would be selected. Like the previous field, if blank is a valid value, you've got to identify a different special value that is not used in the database.

How, though, do users specify that they want to skip this check completely? Easy enough: just enter the special value in the first slot. Then the WHERE clause changes a tiny bit:

where (IMABC in (:pABC1, :pABC2, :pABC3) or :pABC1 = ' ')

Now if the first slot is blank, records will be selected regardless of the content of their ABC code. Note that this makes an assumption that the user will not leave the first field blank and enter data in the other two. For example, the user will probably be confused if all records appear for this:

  Enter ABC codes:   B C

To the user, this might indicate a choice of only records with B or C in the ABC code, but the statement above will not see it that way. Since the first selection field is blank, the other two are effectively ignored. You can fix that by either disallowing a blank in the first field if the other fields are non-blank or making the SQL a little more complicated and testing that all three fields are blank. Your call.

Techniques such as this can be used for all sorts of fields. In another article, I'll show you some code designed to work specifically with dates and date ranges. I'll also show you how to create a dynamic sort order. For now, enjoy your dynamic selection criteria.