Some QLI features, which ISQL does not support (...- 5.6).

1. It runs on the server and a client (as David Schnepper pointed out),
which is needed for feature #2
2. It can connect to multiple databases and run do everything against these
connections (you just add an db alias before the table:
dbaliasx.tableZ.fieldA).
3. It can - within reasonable limits - modify "domains" (global fields) and
the data affected by the change
4. QLI's "query"
- can accept values asking them from the user (a minimal data entry, see
also 'forms' below)
- can edit a text blob field using a text editor (can be configured)
- can show / accept/ edit data in form format (quite usable for prototyping
/ testing) and has a 'format' clause to format a single value
- can use (text)blob data for selection
- has local variables (declare variable)
- can show the records (rows) affected by a delete or update
- can select first X records of the records matching a condition
- uses the query header from rdb$relation_fields
- supports some SQL statements (select, update..)
- has a 'running' expression to show a running counter

5. QLI can define a relation ('create table') based on another (quite
usefull when working with external relations/tables or restructuring a db)
6. QLI has a procedure structure. This actually exists in SQL as stored
procedures, which are not available in GDML.
7. QLI has a report writer for formatted printing (titles, page headers,
pahe breaks, page footers, column headers, report footer, group
headers/footers...)

So, QLI is a reasonable tool for database prototyping / designing and
maintaining and for 'supported' ad hoc queries (a semi-professional makes
the report for the end user). The features of QLI were very usable when all
the work was done on a Vax terminal.

Some of these are obvious tasks of a db management tool (like Quickdesk or
Marathon on WinTel side) or a case tool (though these now available tools
miss some features like reporting). Some will be there in 6.x. The most
valuable, would, IMHO, be multiple db connections. Not just ISQL (or
equivalent) but also in trigger/procedure language. This is not a simple
task. It should handle cross db transactions and 2 phase commit for a start.

Veli-Matti