Subject | GDML/QLI vs SQL/ISQL - was function TOP n FROM... |
---|---|
Author | Veli-Matti Hurskainen |
Post date | 2000-06-26T11:41:45Z |
Paul wrote:
to this list 01/2000.
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 can 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 for query output layout
- 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,
page 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.
VmH
>I'm reposting a non comprehensive list of QLI -features. It was first sent
>GDML (the native precursor to SQL) in InterBase supported a FIRST n syntax,
>but when 4.0 was implemented and a decision was made to support SQL more
>effectively than it was in pre 4.0, the InterBase lead engineer at the time
>for SQL (no names) at that time made a decision that the only SQL that would
>get supported was ANSI SQL the standard, nothing more, nothing less. As such
>a collection of useful capabilities that InterBase had, disappeared, unless
>you had access to QLI. QLI wasn't shipped with 4.0 on Windows, so there are
>a large number of users out there who have no idea that InterBase supports
>all sorts of weird and wonderful capabilities....
>
to this list 01/2000.
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 can 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 for query output layout
- 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,
page 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.
VmH