SQAPL/Client Version 2.0

Dick Bowman

Author's Note: This document contains preformatted text with APL characters, you may be able to achieve a workable rendition by setting up your browser to use the IBM APL2 TrueType font for preformatted text.

In an earlier review (APL Quote Quad Vol. 25, No. 3, p. 25 - March 1995) I was very positive about the inclusion of Insight Systems SQAPL/EL product as part of Dyalog APL/W Release 7.0. I think that it is important for APL systems to deal with data which is produced by or may be used by other applications. One of my regrets about the APL world is the way that APL system designers sometimes cling to the component file as the beginning and end of their data thinking - not only is such data not accessible to non-APL software, it may not even be accessible to APL systems written using another vendor's interpreter. Universal data access is an increasingly important consideration in application design - what SQAPL brings us is a highly flexible extension to our arsenal, making the 'mainstream' database a part of our world.

Since writing the earlier review I have increased my use of Microsoft Access as data repository of choice for PC/Windows applications and was very happy using the inbuilt SQAPL/EL product of APL/W. I was keen to find out what extra functionality was offered by Insight's Professional Edition - which is what this review is about.

The Constituents

On the surface it is easy to think of SQAPL as introducing extra levels of complexity, but there are benefits to be gained. Instead of a direct interaction between APL and data files there are additional layers of software...

The benefits we get out of this are...

Notice also that by relying on database functionality for controlling multi-user access and commit/rollback processing we have freed up the APL developer to concentrate on application issues and not data management issues.

What particularly intrigued me was the possibility that I could share nested APL data directly between APL/W and APL*PLUS III.


For review I was supplied with a copy of the product compatible with Dyalog APL/W; which was installed onto a 486/33 system running Windows 3.1. ODBC was already installed, with data sources defined - although adding new ODBC sources is a trivial task.

SQAPL/PE (the product has two names - which I find mildly confusing as I write this review, please treat SQAPL/PE and SQAPL/Client as synonymous in your reading) is presented as a single 3.5" disk and a 77-page manual; there are 8 files on the disk which have to be manually copied into your Dyalog directory structure. You also have to edit the WIN.INI file manually.

After performing a manual installation like this I felt that it would have been helpful to have been directed toward a procedure to confirm that the installation was satisfactory. There was none, so I poked around for a while with some examples from the reference manual to make sure that nothing was broken. It seemed alright, but I think that most software vendors are now using automated installation for good reason.

Professional Level versus Entry Level

Basically the Professional Edition offers a wider range of data types than Entry Level, which supported only Integer, Float, Character and Binary data; SQAPL/PE adds a variety of date/time data types along with APL Arrays. The latter is clearly of value for APL-specific applications, while the data and time types clearly ease one of the restricting factors in SQAPL/EL.

The other major enhancement is the addition of a group of functions which allow you to work on sets of records as single entities to a much greater extent than is the case with SQAPL/EL. This clearly makes writing applications much simpler.

An Example

Using SQAPL (either version) is about as easy as you might hope:

First, connect to your data source:

     SQAConnect 'c' 'usenet'

The first element of the argument is a cursor name, the second is the name of the data source.

Now select and acquire some data (there are many ways to do this and I show only one).

     aaa½SQASetPrepare 'c.set1' 'select subject,fromwho from messages'
1359 2

Again, notice that we have a cursor object and we will have to remember it.

Now that we have the data we can do whatever we like (including updating the database entries or deleting some or all of them).

And when we've finished we disconnect:

     SQAClose 'c'

Closing the parent cursor closes all the subsidiaries.

Notice here how cursor names are structured hierarchically, very similarly to APL/W's namespaces in fact. This brings me to the one weakness I find in the product; cursors are a new (and semi-invisible) type of object for the programmer to deal with. They are not variables, or namespaces, or directly visible to the application. Details can be found using the SQADescribe function and I suspect that heavy-duty users will want to create functions to track cursor usage more directly.

Practical Experience

This is a fit-and-forget product, or at least it has been for me (your mileage may vary). To put this into context, I have used it seriously only to connect to Microsoft Access 1.1 (using the SIMBA.DLL ODBC driver) and with relatively small databases with only a few thousand rows in each table.

Not all of my attempts to use SQAPL have been successful immediately and I tend to believe that this mostly driver-related (for example, I have failed in all attempts to use columns names containing blanks even though Access permits this and constructs internal SQL statements which I have faithfully copied). But I have always been able to find a way to achieve the required result ultimately.

Something which SQAPL does bring home is that databases are more complex than flat files, and will behave badly if you treat them badly. Proper application of indexes will make all the difference to performance; but this applies to the whole of your database use and not just the APL interface. With a properly set up database I detect no performance shortfalls when using ODBC and Access as opposed to earlier incarnations of some of the applications I have used here.

Databases which I have set up for use with APL/W applications are as easily manipulated from J (using J's own ODBC interface), and vice-versa. I have no reason to doubt that SQAPL for APL*PLUS would yield any further problems.


There is a lot more to Insight Systems' SQAPL product range than interaction with standard databases - this review has concentrated on just one aspect.

Clearly, being able to make a connection from APL to industry-standard database products is a very worthwhile step forward. It has been possible for a long time in more proprietary contexts (APL2 and DB2, for example), and Insight Systems are not the only APL vendor to be making these connections (ref. [1]).

Something which I would like to know more about is the availability and relative performance of ODBC drivers; I am sure that Insight are able to advise on this.

Including SQAPL/EL as part of APL/W was a shrewd marketing move by both Insight Systems and Dyadic Systems; I sense that there are probably few things which are achievable by SQAPL/PE which could not be managed using the entry level product - but only by the programmer expending more effort (perhaps a lot more effort).

This is a product which extends the reach of APL, and is therefore recommended.


[1] Recycling APL Code into Client/Server Applications; Busman, R., Fil, W.G. and Kondrashev, A.V.; APL Quote Quad Vol. 25, No. 4, pp 20_27; June 1995

Back to the J\APL Contents Page

The Journal of APL is produced by Dick Bowman

Copyright © Dick Bowman 1995-2013; latest update 15 March 2013 (repaired links)