× 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.



I have to say i don't agree with everything said below. Some statements
are true, If I change a file, I need to recompile everything that uses it.
But I rarely read a whole file to process a few records, RPG has ways
around this using SETLL, and READE (which I'm sure you are well aware of)
to get just the part of the file I care about. I also personally hate the
database independence argument, I like the DB2 data base as deployed to
the iSeries servers. I don't care about independence, My RPG program is
not going to be run on another system. There are times when using SQL
makes sense, but to say never use native IO is wrong in my opinion.

This still gets down to personal preferences. A lot of RPG seems to be
that way.
Use the right tool for the right job.
Can't we agree that very few things are ALWAYS best. Sometimes it depends
on what you are doing.




"Alan Campin" <Alan.Campin@xxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
04/01/2008 12:50 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
<rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: Wrongly using embedded SQL






<snip>
IMHO The answer is, as always, it depends. A couple of
years ago a Rochester DB2 expert told me that the
performance threshold between "RPG-Native" and SQL was
about 100 records (<100 records, RPG was faster).

That said there are, of course, many additional factors,
depending on your business needs and requirements (or your
customer's). For example, if the query is very complex I
like to wrap it on a view.
</snip>

As usual, I think we are focusing on performance issues where the big
issue from my perspective is Database Independence and the costs
associated not using it. If you are using SQL properly, then you are
only bringing in what you need to the program and the logical view of
the database is different from the physical view. Using files means
reading in the entire table. Want to make a change to the tables.
Recompile the whole world.

Using tables also means using program logic to select records instead of
database logic. Read a record, check a value, read another, check value
and check another value, etc, etc instead of just writing an SQL that
gets you what you want.

As I have stated before, always use SQL unless you have a very good
reason not to. (Un-Normalized tables, performance just to slow, etc).

I think the Wiki article would be a good idea if it summarized all
reason for using SQL and the negatives you would have.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.