× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> 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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.