In the May/June 1995 issue of PC Support Expert, I described the Database Access GUI (DAGUI) program provided with Client Access/400 for Windows 3.1. That program lets you create queries that run against AS/400 database files, using the ODBC driver provided with CA/400. One of the output options for the query is an Excel spreadsheet. But there is an additional option you can use, in which you can activate a query directly from within Excel.

I’ll tell you how this embedded query option is enabled, then show you an example of using the embedded query. I’m assuming that the query is already described and saved; I’m simply using it from within Excel.

Why You Might Want to Use Embedded Queries

For your users, it’s advantageous to have the DAGUI functions directly available within Excel. They are probably more used to working with Excel than with query functions. You can define and save the queries for them; they simply have to pick the query they want to work with. You can achieve the same result by starting DAGUI and selecting the Excel output option; however, if you make your users use this technique, they are exposed to the query builder itself. For most users, it makes sense to create the queries they need, then package them within the application where they are used, rather than allow them access to the query construction tools.

You should also assess how you are currently providing data to your Excel users. You might be using the CA/400 file transfer function to download AS/400 data to a PC file, which your users then import into Excel. If you need the capability of downloading several files at a time, you might want to continue to use the file transfer technique. But if you find that your users are downloading a file, then immediately importing it into Excel, you should investigate the embedded query technique. With the embedded query, there is only the one step, and that step is performed within Excel.

How the Query is Embedded

When you install CA/400 on your PC, you can optionally install the Database Access GUI program. If you install that program, the install process examines your PC to see if you have Microsoft Excel version 4.0 or 5.0 installed. If you do, the DAGUI program is configured as an add-in for Excel. This makes the DAGUI program available directly within Excel. You don’t have to start the DAGUI outside of Excel.

Excel knows that it has the new add-in function by the addition of two lines to the EXCEL4.INI or EXCEL5.INI file. (On my system, EXCEL5.INI is in my WINDOWS directory.) Figure 1 shows the two lines that are added to EXCEL5.INI. The lines need to be in the order shown. These lines are automatically inserted if you have Excel on your PC when you install DAGUI. If you install Excel after DAGUI, you’ll have to manually add the lines to your EXCEL5.INI file.

Using the Embedded Query

To use a DAGUI query within Excel, you first create the query and save it in DAGUI. This is the step that you’ll probably want to perform for your users. You need to be familiar with the AS/400 ODBC driver, configuring it for AS/400 data sources, and designing and verifying SQL queries against an AS/400 data source. If you haven’t previously done this, it is not much more difficult than using the OS/400 Query/400 program. The big difference is that you need to use ODBC to get the data from the AS/400 database to your PC.

Once you have a saved DAGUI query, you can start Excel and run the query as an embedded query. You need an active CA/400 router connection to your AS/400 before starting an embedded query. To start the query, use the Data:Activate RUMBA menu item, shown in Figure 2. After selecting this menu item, you’re shown the SQL Data Sources selection list. That is a list of data sources you’ve configured using the ODBC drivers that are installed on the PC.

In my tests, the ODBC Driver Connection dialog was shown next (Figure 3). This shouldn’t be necessary, as all of the parameters on this dialog are available from the SQL data source selection. It is unfortunate that this dialog is shown, as it is certain to cause confusion and concern with your users. You don’t need to enter or change anything in this dialog; simply click OK to continue with the embedded query.

At this point, the ODBC driver connects to the AS/400. This can take from several seconds to several minutes, depending upon how many libraries are associated with the data source and how many tables (files) are in those libraries. When you configure an ODBC data source for a user, you should specify only the libraries that contain files they need to access. If you can, you might consider creating a separate data source for each library they need.

After the ODBC connection is made, you’re back to where you can use Excel. At this point, you use the Data:Get Query menu item shown in Figure 4 to select the saved query that you want to work with. This displays the Get Query dialog shown in Figure 5, which lists all of the saved query descriptions defined on the PC.

A nice feature of DAGUI is how it saves queries: rather than saving a query as a PC file name (8.3), you can spell out a long description of the query. The downside of DAGUI’s saved queries is that there doesn’t seem to be any way to group sets of queries, such as you would do with different directories (e.g., all accounting queries in one location, all personnel queries in another). Instead, all of the saved queries are lumped into the same query selection list. You might want to consider adding a prefix to your saved queries

(using the examples, ACCT for accounting queries, PERS for personnel queries). Using that technique, similar queries will appear in sets in the query selection list.

The Get Query dialog provides some options for working with queries, some of which might defeat the purpose of trying to keep users out of harm’s way. For a saved query, the options your users might need to set are the “Retrieve Data to” and “Number of Records” selections. The saved query is activated with the Retrieve command button. Clicking Close takes you out of the Get Query dialog.

The other command buttons may lead to problems. The Add command button lets you create another query and save it in this dialog. You create the query by entering an SQL statement. No prompting is provided, as in the DAGUI program itself. The Edit command button gives you access to the SQL statement for the saved query you’ve selected. Unfortunately, your users can modify an SQL statement using these command buttons, and possibly retrieve unintended data or data that you’d rather they didn’t access.

The Delete command button is possibly the most harmful of all: it deletes the currently selected query, without even offering a confirm prompt.

Run-time Prompting

Figure 6 shows an example of one of the more useful features of DAGUI: run-time prompting. When you define a query, you can set parameter markers in the query. When you run the query, the prompt text (marker) is displayed along with an input field. The values that you enter for each field are used in the SQL statement. As shown in this example, I am prompting for the name of the member to work with, and a year and month date selection.

Pros and Cons

Using DAGUI to embed queries is like using any other program: there are advantages and disadvantages. The primary advantages are that you can keep your users in the Excel environment, and that you can use the run-time prompting feature of DAGUI to dynamically select data without having to directly modify the SQL statement.

The biggest disadvantage of the DAGUI embedding is that there are still too many modification factors exposed to your users. This seems to be a common failing with many Windows products: although it’s great to have everything be configurable and easy to change at the click of the mouse, there are many times when you’d really rather not provide users with modification capabilities. This problem is also very evident in emulation programs, where it is almost impossible to “lock in” a configuration so that users can’t change it.

Member Selection

I skipped over the “member selection” parameter in Figure 6 on purpose. One of the major problems with ODBC on the AS/400 is selecting the member to use in a multiple-member database file. In the next issue of Client Access/400 Expert, I’ll describe the technique I’m using in this example to allow you to select the member.

[Microsoft Excel] OPEN=/R C:CAWINRUMBADA.XLL OPEN1=/F /R C:CAWINEXCELRUMBADBA.XLA

(The OPEN and OPEN1 statements are added.)

Figure 1: Statements Added to EXCEL5.INI

Figure 2: The Data:Activate RUMBA Menu Item Figure 3: CA/400 ODBC Driver Connection Catalog

Figure 4: The Data:Get Query Menu Item Figure 5: The Get Query Dialog

Figure 6: Run-time Prompting with DAGUI