There's no reason not to forge ahead with new techniques such as SQL as long as you have the right tools in place.

Structured Query Language (SQL) is a keyword-oriented language, which makes it easy to learn and use, and it's an excellent application development tool. You can define data, manipulate it, and query it to get fast results.

SQL is also an industry standard, so learning it on the IBM i means you've learned it for other platforms as well. And that means you can increase your application's portability, yet keep the way you access the database standard. That simplifies maintenance of your systems, and it makes development easier, which in turn leads to productivity. SQL is required if you want to move data between platforms effectively and efficiently.

SQL can be used interactively on the IBM i, or it can be embedded within the programs that make up your applications. This article examines some SQL techniques and the issues with using those techniques. It also offers some solutions to help you manage SQL items.

Setting the Stage

Let's assume you've been asked to develop a new employee time-tracking system. This system will need to run on the IBM i as well as other platforms. Because SQL is the same regardless of platform, it's a good choice for designing this new system.

To start, you would figure out what information the system would need and design the database. In this example, you would surely need an employee master file that would contain information like name, date of hire, type of employee, salaried or hourly, etc. The information in this file would relate to other files, like the employee type code file, the employee status code file, and so on. To keep the data clean, you would probably include a few constraints and possibly use a few foreign keys.

In order to create the database tables, you would more than likely start an SQL session and interactively issue SQL statements. To create the employee master table, you would use the CREATE TABLE statement. (An SQL table is really nothing more than an externally described physical file object.) In that table, you would define the columns (fields) found in the rows (records). It's basically the same architecture you're used to; we're just using some different terms to describe it.

The statement you use to create the employee master table might look like the one shown here:

CREATE TABLE EMPLOYEE (                                           

  EMPNO DECIMAL(5, 0) NOT NULL DEFAULT 0 ,                        

  EMPLNM CHAR(25) CCSID 37 NOT NULL DEFAULT '' ,                  

  EMPFNM CHAR(25) CCSID 37 NOT NULL DEFAULT '' ,                  

  EMPMIN CHAR(1) CCSID 37 DEFAULT NULL ,                          

  EMPTYP CHAR(1) CCSID 37 NOT NULL DEFAULT '' ,                   

  CONSTRAINT Q_DEMO_SQL_EMPLOYEE_EMPNO_00001 PRIMARY KEY( EMPNO ) )  NOT VOLATILE ;          

As you can see, this statement creates the table and identifies the columns that will be in each row. As you proceed through your design, you create other tables that contain other information you need for your system. At some point, you might decide that fields within the employee master table must match fields found in other tables. In other words, you want referential integrity built into the database. You do this with constraints and foreign keys. To make sure the data found in the employee type field in the employee master table is good, you might add a foreign key constraint, as seen here:

ALTER TABLE EMPLOYEE                               

  ADD CONSTRAINT Q_DEMO_SQL_EMPLOYEE_EMPTYP_00001 

  FOREIGN KEY( EMPTYP )                           

  REFERENCES EMPTYPE ( TYPCDE )                   

  ON DELETE NO ACTION                             

  ON UPDATE NO ACTION ;         

Again, you would use an SQL statement in an interactive setting to perform this operation.

Once the database is built, you would start programming over it, again using SQL embedded within your RPG to get the job done efficiently. Code within your programs that accesses these tables might look like what you see here:

C/exec sql                          

C+ select count(*)                  

C+   into :counter                  

C+   from demo_sql/employee         

C/end-exec                              

This statement would give you an employee count if used in a program.

You can see the techniques used here are efficient, easy to use, and portable across platforms.

The Issues

The issues arise when you need to maintain these items or enhance an existing system that was built using SQL. Because the database was built using SQL statements in an interactive setting, there's no source code for it. It's possible that the developer who built the system did create some source members containing the SQL statements needed to create a particular file, but what if an ALTER TABLE statement has been used since then? How can you efficiently make changes to these tables and maintain referential integrity without source? The programs using these files may not refer to them in an F-spec. They may only contain embedded SQL as seen above. How do you know what programs a certain table is used in? Where is this table updated? What views and indexes exist over this table?

Using SQL is not the issue; everybody should be using it by now. Managing a system created using SQL is the issue. Shops that develop programs using these modern techniques need a modern solution in order to gain control over the process. That's where change management systems come into play.

Solutions

Repository-based change management solutions can help you handle the SQL issues mentioned above and more. The central repository contains all the information needed to control a given set of libraries or directories. When the repository is created, automatic processes in a modern change management system can actually parse through your code and find references to files, even if they are found in embedded SQL statements. Look at Figure 1:

Figure 1: WDSc plug-ins let a developer access the repository. (Click images to enlarge.)

In the above screen shot, WDSc plug-ins let a developer access the repository and use the information found there for impact analysis and for making changes. In this example, we can see the employee table has an index and a view associated with it.

Figure 2 shows the programs that use the CUSTMAST file in embedded SQL statements. They are located and displayed by the change management tool.

Figure 2: The change management tool displays the programs that use the CUSTMAST file in embedded SQL statements.

You can see all references to this table in the system, and further, in most instances, the change management tool can identify how that file is being used in a particular program.

The change management repository is the backbone of managing modern applications created with techniques like SQL. Let's examine an SQL change using change management software, and you'll quickly see how useful and effective it is.

An SQL Change

All changes within the change management tool are accomplished in a version. A version is nothing more than a container for all the objects, source, and documentation associated with a particular set of changes.

In Figure 3, you see the WDSc plug-ins displaying a version, and in this version, you see several tables, an index, and a view. Also, note the command line on the lower left corner of the screen. Using this command line, you can create all the tables and views you would like.

Figure 3: The WDSc plug-ins display a version.

Notice the command that is entered in the command line in the above example: Retrieve SQL Source (RTVSQLSRC). If you need to change a table, you can use the command line and the ALTER TABLE statement and then use the RTVSQLSRC command to quickly and easily create the source needed by the change management system.

Figure 4 shows the created source:

Figure 4: This is the created source code.

Notice that the source contains all the statements required not only to recreate the table, but to manage any constraints that may be present. Simply put, it means you can right-click the table and ask the system to compile it for you now. You could make a quick change to the source and issue the compile or make the change and then retrieve the source for use within the change management system when needed. Either way is valid. The RTVSQLSRC command makes it easy to meet the need for source code.

Within this version, the CUSTMAST table has been recompiled. Remember that the change management system's repository contains cross-reference information for programs, even if the file is specified in embedded SQL. As a result of recompiling the CUSTMAST table, the list shown in Figure 5 was generated:

Figure 5: This list was generated as a result of recompiling the CUSTMAST table.

These are the programs that need to be recompiled in order to avoid problems in the production environment as this change moves forward. Click one icon, and these will be recompiled for you within the version, and you'll be ready to test them.

Your change management system will make sure, even when using SQL, that all items that need to be considered are considered for complete version integrity.

Manage Your Apps

Using modern techniques like SQL to create your applications is a must. As applications spread out and move onto other platforms, it just makes sense to implement a simple way to manage these applications.

A good change management tool will allow you to create tables, views, and indexes and embed SQL code in your programs with ease. You'll be able to create or make changes to SQL items and transfer them to testing and production using the same proven process that handles your native PF, LF, and RPG source. You will have complete cross-reference support, and your system's referential integrity will be maintained automatically. A modern, comprehensive change management tool will manage all of it for you. There's no reason not to forge ahead with new techniques such as SQL as long as you have the right tools in place.

Also Read

SQL 101: DDL Recap—Improving Our Basic SQL Tables, Part 2

TechTip: Automate Complex Tasks Using SQL and User-Defined Table Functions

SQL 101: DDL Recap—Improving Our Basic SQL Tables, Part 1