>The one SQL extension I would like to see carried from QLI to the Interbase
>SQLdialect is the ability to deal directly with two databases in one SQL
>statement. For example, to be able to insert records from a table in one
>database by selecting them from another.

It is NOT likely that this will be a part of the SQL dialect. The way
InterBase handles SQL is it is all compiled and processed on the server, not
the client. It takes a client in order to establish a connection to a
database server so because of this the two connections must be operated on
from a client-side operation only. Putting two and two together here
suggests that it won't be possible to defer processing of something on the
server that is only possible from a client.

This made sense to me but my intuition tells me I may confuse most everyone
else. If so, my appologies. Perhaps someone else can make sense of this for
me in layman's terms?

If you use the TIB_DataPump that comes with IBO it allows you to do exactly
what QLI does only I have a lot of other posibilities to make it more
flexible and extendable. If QLI uses the API (which I suspect it does) then
my TIB_DataPump component will equal or exceed the performance of QLI.

What needs to be made is a rich script dialect that resembles a stored
procedure except it allows transactions and connections. Kind of like the
embedded dialects but a fully stand alone interpreted IB Client Script
engine... (Just another feature I'd love to add to my IB_Script component!)
It would be kind of like PL/SQL for InterBase...

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

Developers Search Site http://developers.href.com