That is how InterBase handles DSQL. Embedded SQL is parsed and
processed on the client at pre-compiler time. ESQL also supports the
ability to interact with different databases in the same module -- but
not within a single SQL statement.

As I mentioned in prior message, a distributed query ability within
the engine would make this possible.

(Or, an alternate way of approaching this -- extend the ability for
external tables to include data sources beyond local-flat-files. eg:
dBASE files, paradox files (which would query to the BDE perhaps?) or
a generic ODBC source, or another InterBase source, or an Oracle
source, etc.) This brings up the messy issue of "varients of standard
SQL" -- but programmers can deal with that on a case-by-case basis.

Dave




-----Original Message-----
From: IBO [mailto:jwharton@...]
Sent: Saturday, January 15, 2000 3:27 PM
To: IBDI@onelist.com
Subject: Re: [IBDI] QLI and ancient IB language


From: "IBO" <jwharton@...>

>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



--------------------------- ONElist
Sponsor ----------------------------

Hey Freelancers: Find your next project through JobSwarm!
You can even make money in your sleep by referring friends.
<a href=" http://clickme.onelist.com/ad/jobswarm1 ">Click Here</a>

----------------------------------------------------------------------
--

Community email addresses:
Post message: IBDI@onelist.com
Subscribe: IBDI-subscribe@onelist.com
Unsubscribe: IBDI-unsubscribe@onelist.com
List owner: IBDI-owner@onelist.com

Shortcut URL to this page:
http://www.onelist.com/community/IBDI



[This message contained attachments]