RE: sql exec speed. was something else

> It may not be as fast as Chain/Update,   However,  It may get faster than
> SETLL/READE.
> I've found that passing the Where and Order By clause to my External I/O
> module and passing back a
> multi-occurring D/S with (say)  50 records just as fast and maybe faster
> than a do loop Reading each individually.

Interesting.  In my copious free time, that will go onto the performance
test list.  Now that version one of revitalization is ready for beta
testing, I may be able to spend a little time on the performance tests I've
wanted to do forever.


> The validity of the statement "SQL is the way of the Future"  is
> that it is
> like JAVA so to speak.
>
> The Skills and code is transportable.   Before you go off Joe,
> The code is
> magnitudes more portable than READE.

Perhaps.  I'm not going to go off on this, really.  For queries, it may well
be easier to teach SELECT to a newbie than a key list.  On the other hand,
if you have a hard time with the concept of a key list, I wonder if you
ought to be coding database applications?  Just an observation.

Or maybe we're seeing the fracturing of the application world: query
programs that require the flexibility of SQL and transaction processing
programs that require the more nuts and bolts approach of a native database.
I'm okay with that distinction; it answers my previous observation.

Joe