Ann Harrison wrote:
>>
> The people who wrote ISQL had a different sense of architecture than
> the people who created the original product. They recognized that
> replicated code is bad. They also noticed that nearly every subsystem
> has an allocator, a parser, error handler, mover, etc. Rather than
> creating those routines in a mode appropriate for a utility, they used
> the (grossly overbuilt and inappropriate) engine routines.
But at the same time, QLI has an allocator, mover, etc and this means
duplicate functionality, although not necessarily identical to the engine's
code.
> If I were you, I'd take a look at reviving qli rather than civilizing
> ISQL. Qli's SQL is primative but that can be added incrementally. It
> doesn't understand the new INT64 type or database procedures, but they
> should be relatively easy to add. It does have its own notion of
> procedures which are chunks of qli commands, stored in the database.
> What qli does have is multi-database access, conditional's, loops,
> formatting, etc.
The problem with qli is that IMHO has too much private functionality that
needs to be kept in sync with the engine. But it's nice to be able to bypass
the DSQL layer by writing GDML that gets converted into BLR directly.
C.
|
