beginning sql part one

8/4/2019 Beginning SQL Part One

http://slidepdf.com/reader/full/beginning-sql-part-one 1/6

Beginning SQL Part One

Contributed by Sam LennonSaturday, 31 October 1998Last Updated Saturday, 31 October 1998

It?s time you paid attention to SQL.

If you aren’t using SQL or have only a nodding acquaintance with it, this article is for you. It explains how SQL coexistswith DDS, how it can replace procedural code, and how it can make your life easier. This article describes basic syntaxand shows some practical examples that you can run on your own machine. Experimentation with SQL is an easy andinexpensive (free!) way to learn. Even if you are already using SQL, you may find some new techniques in the examples.

The AS/400 comes with a native database management system, DB2/400. Files in this system are traditionally describedwith DDS and accessed a record at a time from a third-generation language (3GL) such as RPG or COBOL. SQL canwork concurrently with native access to allow you to manipulate these files.

“SQL is Rochester’s strategic interface” to DB2/400. So wrote Kent Milligan of the DB2/400 Solutions Team in a recentInternet discussion (find it with Deja News by searching on “SQL is Rochester’s strategic interface”). SQL has been aroundon the AS/400 since at least V2R1, and with each new release of the operating system, IBM has improved both thefunctionality and performance of the product. It is no longer possible to write off SQL as a passing fad.

IBM defines SQL in DB2 for AS/400 SQL Programming V4R2 this way: “SQL consists of statements and clauses thatdescribe what you want to do with the data in a database and under what conditions you want to do it.” This is an

excellent definition, but it needs a little fleshing out, since I could describe an RPG batch program the same way.

SQL vs. DDS

SQL eliminates many of the procedural issues you must deal with when you write applications with a language like RPG.Rather than access and update data a record at a time using controlling procedural logic in a 3GL, with one SQLstatement, you can operate on a set of data. (Think of a set as a group of records with some common characteristic,e.g., all records with the same customer number.) And, with SQL, you generally don’t have to worry about how the data iskeyed or sorted.

In a single SQL statement, you specify what set (group) of records you want, how the set should be sorted, and what youwant done with each record in it. You don’t have to

worry about coding logic to position into the file, to read records in a loop, or to select records for display and/or update.

You can use IBM’s implementation of SQL in DB2/400 by coding SQL statements in a 3GL. You can also execute ad hoc

SQL statements, either interactively or in a CL program by using the Start Query Management Query (STRQMQRY)command. One such statement can often replace a small to moderate 3GL program that uses native access.

MC Press Online

http://www.mcpressonline.com Powered by Joomla! Generated: 18 March, 2009, 01:21



Consider a few other advantages of SQL over native OS/400 data access:• SQL queries can accept parameters. How often have you wanted to have something like this in a CL program?

RUNQRY QRY(LARGEOBJ) +

OWNER(&OWNER) +

MINSIZEMB(&MB) +

UNUSED(&DAYS)

This task would be pretty difficult to do in Query/400 because Query/400 doesn’t take parameters. But it’s remarkablysimple with SQL because SQL queries do allow parameters.

• SQL is like Open Query File (OPNQRYF) when it comes to filtering, sorting, and manipulating data. But since SQL runsinside the program, rather than in a separate CL, you have a lot more control. (I’ve seen some OPNQRYF/3GLcombinations that will run without the OPNQRYF and will cause significant damage in the process.) I find the SQL syntaxeasier than OPNQRYF, and SQL has more functions for data manipulation.

• SQL is largely immune to file changes. Add a field to a file, and programs that use the file will get a level check, unless

you recompile them over the new file. (It’s best not to use the dangerous LVLCHK(*NO) practice.) Query/400 will alsoobject. SQL is much more tolerant and won’t object, though it can’t handle all changes. (For example, it is going to getupset if you remove a field that it was using. And if you lengthen a numeric field that is being read into a program, youmay also want to check that the receiving variable is big enough to hold the new larger field without truncating it.)

• SQL isn’t just an IBM standard. It is the de facto relational database access language, and college graduates will knowmore about it than they will about DDS. (Something to consider in a tight job market.)

• SQL is where IBM is putting its development efforts and has been for several years. Remember the “strategic interface”

comment at the beginning of the article. Some of the enhancements that go into SQL find their way into DDS, but inrecent releases, DDS has been the poor relative.

These arguments are not meant to imply that SQL is going to totally replace DDS and native I/O now or in the nearfuture. However, SQL is powerful enough and efficient enough now that systems can be written without DDS and nativeI/O. SQL is such a powerful tool in the AS/400 developer’s toolkit that is worth getting acquainted with and shouldn’t beignored.

SQL Syntax Overview

The basic statements used to manipulate data are SELECT, UPDATE, DELETE, and INSERT. Each statement has oneor more clauses; for example, FROM and WHERE. Clauses in a statement must come in the correct sequence; for

MC Press Online




example, FROM always comes before WHERE. A typical SELECT statement might look like this:

SELECT ODLBNM, ODOBNM,

ODOBSZ, ODOBTXFROM DSPOBJDWHERE ODOBTP = ‘*FILE’

SQL syntax is free-form, and there is no punctuation between clauses. Lists, like the “ODLBNM, ODOBNM, ODOBSZ,ODOBTX” text shown, are separated by commas. Parentheses are used for grouping and prioritizing.

The following statement is syntactically correct and identical in function to the previous statement but much less readable:

SELECT ODLBNM,ODOBNM,ODOBSZ,ODOBTX FROMDSPOBJD WHEREODOBTP=’*FILE’

In this article, I’ll be using the structured layout for readability.

Examples in This Article

All the examples use a common input file, DSPOBJD, the output of the Display Object Description (DSPOBJD)command. To build such a file, issue a command something like this:

DSPOBJD OBJ(inlib/*ALL) +

OBJTYPE(*ALL) +

OUTPUT(*OUTFILE) +

OUTFILE(outlib/DSPOBJD)

Here, inlib is a moderately sized library containing several different object types with a variety of creation and last useddates; outlib is a library in your library list. It could be QTEMP.

MC Press Online




The records in the file created from the DSPOBJD command contain many fields that tell you all kinds of useful thingsabout the objects in your library.

Are you interested in what else is in the file? The CL manual says: “The database format (QLIDOBJD) of the output file isthe same as that used in the IBM-supplied file database QADSPOBJ.” You’ll find this file in QSYS.

In these examples, I’ll use the fields listed in Figure 1.

Simple SELECT Statements

The SELECT statement in Figure 2 is almost as simple as you can get with SQL: The first line starts the statement withthe SQL reserved word SELECT. It is followed by at least one blank and then a list of field names to be selected, eachseparated by commas and, optionally, one or more blanks. At least one blank must follow the last field selected. In this

example, I’ve selected the object name, the object type, the size of the object, and the object description.

The second line is the FROM clause; it specifies the file from which the data is to be selected.

Try running this SQL interactively. (See the “Use SQL Free!” sidebar if you need instructions.) You should see a report thatis formatted like Figure 3.

Obviously, your data will be different, but you’ll notice that the DDS column heading text has been used to identify thecolumns.

Here is the simplest useful SELECT statement you can run:

SELECT *FROM DSPOBJD

The asterisk character (*) is shorthand for “all fields in the same order they appear in the record.” Run this statement, andyou should see a report that runs off the right of your screen, formatted like the one in Figure 4.

If you keep scrolling your display to the right, you’ll eventually come to the end of the data. (For Query/400 users, this isfunctionally equivalent to RUNQRY *NONE DSPOBDJ). A maximum of 8,000 fields can be retrieved this way.

The WHERE Clause in the SELECT Statement

Suppose you want to list just the files in your library; you would include a WHERE clause, as shown in Figure 5.

MC Press Online




Run this, and you’ll see that, indeed, only files are listed. (Presuming, of course, that you ran DSPOBJD over a library thatincluded some files.)

This WHERE clause introduces the equal to (=) relational operator. The other operators are greater than (>), greater thanor equal to (>=), less than ( 70000

)

Figure 6: A complex WHERE clause

SELECT ODOBNM, ODOBTP, ODOBSZ, ODOBTXFROM DSPOBJD

WHERE ODOBTP = ‘*FILE’

Object Object Object Object Type Size Owner CMPC *PGM 77,824 LENNON$S CMPFSC *PGM 73,728 LENNON$SMUSICT1D *FILE 238,305,280 LENNON$S

Figure 7: Results of a complex WHERE clause

SELECT ODOBNM, ODOBTP, ODOBOW,

ODOBSZ/(1024*1024) AS SIZE_MBFROM DSPOBJDWHERE ODOBOW = 'LENNON$S' AND ODOBTP = '*FILE'

AND ODOBSZ/(1024*1024) > 200

Figure 8: Using an expression

Object Object Object Type Owner SIZE_MB MUSICT1D *FILE LENNON$S 227.265625000000000000000

Figure 9: Results of using an expression

SELECT ODOBNM, ODOBTP, ODOBOW,

DECIMAL(ODOBSZ/(1024*1024),7,2) AS SIZE_MB

MC Press Online




FROM DSPOBJDWHERE ODOBOW = 'LENNON$S' AND ODOBTP = '*FILE'

AND ODOBSZ/(1024*1024) > 200

Figure 10: Using a function

Object Object Object Type Owner SIZE_MB MUSICT1D *FILE LENNON$S 227.26

Figure 11: Results of using a function

MC Press Online


beginning sql part one

Documents