RE: sql exec speed. was AS/400 STILL wearing the undeserved "closed system" moniker

> This is a fairly common algorithm in transportation (trucking), where
> tariffs with thousands of rows and 10 columns (or more) are updated by a
> fixed percentage.  I do it in RPG anyway because we require an audit trail
> and have lots of conditions.  Yes, this is not a classic business
> application but that doesn't invalidate the issue.

I'm not saying there's NEVER a use for SQL for update.  What originally
prompted my remark was the comment that "The Native methods READE, SETLL,
OPNQRYF will not perform as fast as SQL in the future."  That led to the
tangential discussion of where SQL is appropriate.

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


> I like LF's; they're highly intuitive (or more intuitive than SQL coding)
> and easy to share across programs and applications (which reduces
> the chance
> of program errors caused by mismatched SQL coding).

Standardizing SQL access via stored procedures is a way around this, but as
I've said in the past, by the time you get to stored procedures, you should
be writing servers.  With servers you get full control of the database,
including features such as granular security (at the field content level)
and recovery/restart (unlike COMMIT/ROLLBACK, with recovery/restart you can
actually finish a partially completed transaction when your server comes
back up).


> Yes, SQL is the way of the future,

I think the jury is still out on this issue.  I've seen large applications
that were converted to SQL access and the performance suffered horribly.  In
these days of more cost-conscious IS departments, the concept of having to
buy a grossly overpowered server just so that you have the option of miving
to a DIFFERENT grossly overpowered server isn't particularly fiscally
responsible.  And that's why I shake my head when someone says "SQL performs
better than native access".  At what?  Certainly not at transaction
processing!

And that's why I've worked so hard on my revitalization techniques - so that
you can write applications in native RPG and run them over a web interface
on a box that supports dozens - even hundreds - of users for a low
six-figure total cost (and without the associated costs of a fleet of
network and database administrators).

Joe