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



Of course, you are right that explicitly specifying the columns is better
for performance. But then, the pgm becomes a little less simple.
In traditional RPG Read or Chain, the pgm receives all values. So, 500
lines later, I can confidently use the value because the Read or Chain has
brought it >> in. Specifying the columns, means that I no longer have that
assurance.
Specify the columns and the benefit is performance gain. The drawback is
having to be far more careful about what field values the pgm knows and
which >> ones it doesn't know.

But using Select * means giving up the most important reasons for using SQL,
database independence. If we were to add up the cost to companies of using
file I/O and copying the entire database into every program the costs would
be astronomical. Being able to change the database without having to
recompile the world is an absolutely critical capability. Using Select *
gives all that up and we are back to where we were.

On Mon, Dec 7, 2009 at 8:13 AM, Taylor iSeries <tayloriseries@xxxxxxxxx>wrote:

Hi
To Dennis and Birgitta
Thank you very much for your explanations. Now I understand. Now it makes
perfect sense.
In the spirit of friendly discussion, let me answer some of the questions
you intelligent gentlemen brought up.....

*****************************************
Dennis asked,
"What value would you expect SQL to set?"
I expected that the fetch would set the field to null and then the RPG
Eval-Corr would simply copy the null to another null capable field.
Now I know that must not try to copy a Null to another field.

*****************************************
Dennis said,
"eliminate all references to *IN indicators."
Why are the intelligent iSeries people so against the simpler aspects of
RPG. I confess that I prefer to use the simpler conventions in RPG because
they are simple to use.

******************************************
Birgitta said,
"it is never a good idea to use SELECT *,"
Of course, you are right that explicitly specifying the columns is better
for performance. But then, the pgm becomes a little less simple.
In traditional RPG Read or Chain, the pgm receives all values. So, 500
lines later, I can confidently use the value because the Read or Chain has
brought it in. Specifying the columns, means that I no longer have that
assurance.
Specify the columns and the benefit is performance gain. The drawback is
having to be far more careful about what field values the pgm knows and
which ones it doesn't know.

*****************************************
I say.....
Yep, it's a much more complicated programming model that now exists. Maybe
simplicity is a thing of the past.
Thank you very much for posting your answers and helping the simpler (me)
programmers.
Have a great day



--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



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.