Back in June, I wrote a column describing, among other things, how to use IBM's index access object to speed up record-level access. Then I got a letter--well, an email--from IBM's own Troy Bleeker:

"Chris,

I just saw your article in my email. I own the OLE DB provider that you wrote about for MC Mag Online. Thank you for a good, detailed article. Well written. You have hit the essence of the usefulness of record-level access: quick look-ups."

This is very technical language, so permit me to translate: "Devous, you are brilliant. Your keen mind and sharp wit are overshadowed only by your rational and humble personality. You should be writing operating systems, not articles! You are severely underpaid!"

There, that clears that up. Troy continued:

"However, I'm writing to tell you that you might want to investigate the Seek method of ADO. You said ADO did not have one, but it has. Ever since ADO 2.1 (I'm pretty sure), but certainly 2.5 on up has it.... We added support for this method in V5R1M0. Many customers should be moving toward this release if not already there."

He's right. I did say that, and I was wrong. What I should have said was that the Client Access ADO provider that comes with Client Access Express V4R5 and below doesn't support use of ADO's index property or seek method. The column dealt, in part, with using IBM's AD400 index object to overcome this limitation.

Troy added:

"Why is it important? Who cares? Well, we are recommending that people stop using the AD400 index object. It will not get any enhancements. For example, it will not be 64-bit processor enabled. Also, it requires jobs on the AS/400 to do its work. The index.GetBookmark must operate on a second job to find the bookmark, then that bookmark is used on the recordSet. Move, and the real job gets positioned. It was only meant as a workaround while ADO did not have the support. Since ADO has that now, everyone should be using it.

"Our Visual Basic wizards in V5R1M0 generate VB code without the index object and our V5R1M0 samples, downloadable from the Web here, http://www.ibm.com/servers/eserver/iseries/access/oledb/samples.htm use the new recordSet.Seek() method as well.

"I just thought you might want the latest info to make your next, follow-up article (hint) the best it can be.

"Thanks,

Troy C. Bleeker
IBM eServer iSeries Data Providers"

Thanks for the hint, Troy, and the kind words.

So, how can you move from using the AD400 index object to using the IBMDA400 provider's seek and index support? Well, it ain't as hard as it sounds, so here we go!

Excel-lent Beginnings

In the June column, I detailed how to create a table with an index and then access records in that table using its index. The purpose was to update records in an Excel spreadsheet based on iSeries data. That example was pretty detailed because I wanted to illustrate the power of the ADO provider when combined with indexes and the use of SQL. Since we're only concerned with one topic here, we'll use something a little simpler.

For this month's example, I've created a spreadsheet with a list of UPC codes. The codes represent products, but let's pretend we don't know which products and need to find out. Let's use a VBA macro to process each record in the spreadsheet, and then do a seek to find the UPC code on the iSeries, and then fill in the blank fields.

The Building Blocks

The product I am working with is sportswear--polo shirts and T-shirts. The UPC translates to a specific style, color, and size of shirt, with a specific logo embroidered on the left of the chest. I know the UPC, and I want to know what values the other components are.

Figure 1: What goes where?

The table in Figure 1 details what the various columns of the spreadsheet contain. Since I have the UPC code, it'll be the VBA project's job to fill in the remaining columns. So, I'll access the VB editor in Excel (either from the Tools menu or by pressing Alt+F11) and insert a module.

Before I start writing code, I need to add the Microsoft ActiveX Data Objects library to my project references (it's on the Tools menu in the VB editor). This will include the objects I need to get at the iSeries data. Remember that the example here assumes I have the Client Access Express V5R1 or better data provider installed. The provider is included with Client Access and installs by default.

How I Did It

Now for the code:

The meat and potatoes come in two different parts of the dish. Here's the meat:

I defined the cnIseries variable and the recordset variables above the start of the subroutine so that they would be global to all the subroutines and functions in the project. If I decide to add to this, anything I add will also have visibility to these globally scoped variables.

Note that the recordset object uses a server-side cursor. The index property (upon which the seek depends) requires a server-side cursor. I also have to set the index and cursor properties before I open the recordset. The open command uses IFS syntax, naming the file by its IFS path. *FIRST and *NONE refer to members and journaling, respectively. This syntax applies to both the index property and the open statement.

In opening the file, I name my connection (cniSeries), cursor type, lock type, and command type. In the example, I've used a static cursor, which will not reflect changes made by other users. Seeing changes is not important to me in this context, so I'll avoid a dynamic cursor and speed up performance. I could also use a forward-only cursor for even better performance. For this application, it would work, but the limitation would be that I could only move forward through the data. (See your ADO documentation for a full explanation of cursor types.)

The lock type tells the provider what type of lock to put on the records. Since I'm not updating, I've used read-only. The command type tells the provider how to interpret the command string. In this case, I've told the provider that this is a table whose columns will all be returned. I could also use an SQL statement, a stored procedure, or a persistent recordset. (See your ADO reference for a complete explanation.)

I then move the pointer to the first record in the recordset. Without this, the seek will not correctly function because you must access the recordset for the seek to return EOF when a match is not found on a seek equal. Note that with a server-side cursor, you have to explicitly release the record or close and reestablish the recordset to move the pointer.

Now, the potatoes:

UPCKey is a variant. To do the seek, make it an array of values. This is very like establishing a keylist in RPG. You can use all of the key fields or the first few. If you use more than one, you have to go in order, following the defined key. For example, if your file is keyed on Field 1, Field 2, and Field 3, you can use Field 1, or Field 1, 2, and 3, or Field 1 and 2, but not Field 1 and 3.

So you set up your key list by using array(Value, Value, Value...). In this case, I'm using only one key, so I use only one value. Then, I execute the seek.

It should be noted that, at this writing, the seek method incorrectly assumes that the order of key fields in the key list will match the order of those fields in the table. That is, if you have a table with Field 1, Field 2, Field 3, it is assumed that you won't create a key like Field 3, Field 1. There is an APAR on this issue (SE08268), and it should be resolved shortly. In the meantime, for multiple key seeks, build your logicals so that the fields are in the same order as the physical.

When executing the seek method, you must provide the key and the seek type. In this case, I'm looking for a record equal to my key, so I use the adSeekFirstEqual value. This will find a match or set the recordset to EOF if there is no match. If you are not at end of file, set the value in your cells and search for the tape description in item master, using the same technique used for the UPCbyUPC recordset.

Figure 2 shows the seek types and what they do:

Figure 2: This table shows the seek type enumerators.

Running the macro fills in the values, as shown in Figure 3:


Figure 3: The spreadsheet...before and after.

Like the AD400 index provider, this method is lightning fast. It also has the advantage of lower overhead at the iSeries than the older method had. If possible, you should begin using this in favor of the AD400 index provider, which is more or less discontinued and will not be supported on the new 64-bit machines.

This technique is particularly useful when you want to open one recordset but look for records matching varying values. When SQL won't do, this can be extremely useful. I encourage you to try this at your own site, because it can help you to produce more powerful applications, and your users to work more productively.

Drat! He got me! OK, I gotta get my focus back on Doom!


Chris Devous is the Director of IT Systems Development at The Antigua Group, Inc., a Peoria, Arizona, garment manufacturer. Chris has been in IT since '82 and lives Arizona with his wife, three children, a bird, two dogs, a cat, and various marine life forms. He can be reached by email at This email address is being protected from spambots. You need JavaScript enabled to view it..