RE: sql exec speed. was something else

[jpcarr@xxxxxxxxxxxx]

>I'm still waiting for someone to explain to me how SELECT and UPDATE can
be
>faster than CHAIN/UPDAT for normal transaction processing.
>Joe


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.

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.

This is from a 20 year RPG person who Writes in RPGIV every day.  I use
Chain/Update everyday.  I also have written External I/O  drivers using SQL
and nearly always jump into STRSQL now instead of WRKQRY.  The Embedded SQL
stuff doing Summary functions (Group by) bringing back totals is MUCH
better in SQL than Reads and MUCH better than OPNQRYF.

(as a side joke,  how many times did you want to break the hands of a newby
when they used F4 on the QRYSLT clause???   How many quotes did you end up
with?  Quote, quote, CAT quote CAT quote, can't quote enough quotes to save
your life quote un quote'

John Carr