RE: RPG400-L Digest, Vol 5, Issue 1053

<snip>
I am not a big fan of the external data structure for all fields in a
file 
and then doing a select * into :extds for reasons previously mentioned.
</snip?

Sorry Rob but to me this defeats the whole purpose of using SQL in the
first place, database independence. By bringing in the entire table, you
are again hard coding the physical view of the data. I only want to
bring into the program exactly what I need. My logical view of the data
is different than the physical view. The whole concept of a relational
database and SQL is to do just that. Separate the physical view of the
data from the logical view. 

Of course, the other issue for me is that by having a single select for
each table we are not thinking in SQL again.

Also and unfortunately SQL does not think in terms of data structures. 

If you look at the underlying code you will see that all the
pre-compiler does with the data structure is convert it to individual
fields so in an example, MAPICS ITMRVA table contains 111 fields so SQL
generates 111 moves to 111 separate fields vs say two if I needed just
two fields that a big difference. 

If I use the previous SQL as an example, I would end up doing 1,496,748
fields moves ((5423 records in POITEM * 134 fields) + (5423 * 31 in
WHSMST) + (5423 * 111 in ITMRVA) vs. doing 183 field moves (61 records
read * 3 fields). I would consider that significant and the other issue
being that each one of these :extds is defined in global storage.  

<snip>
All good points Alan but I would tend to agree with Joe, mainly because
the stuff any new person is likely to be working on will include "old
style" code, and while it is good to be able to service the latest
Ferrari, most mechanics will still need to be able to look after the
older Rover Metro's too.  :-) 
</snip>

I have always had a different training logic than most other people that
I know. Most people when they have a really simple program to do just
bang it out. My concept was to always do the opposite. Push the window
when I am doing simple programs. My thinking here is clear. If I don't
do that, when it is time to do the tough stuff, where have I trained? 

My thinking is the same here. If he or she just learns the old stuff
because that is what they use mostly when does he or she have the new
stuff when they need it? You are building a new program. Use SQL and how
it works. If they just use Record I/O, when they need SQL how are they
going to know it? 

My point is always the same. Unless you practice with something you are
never going to get to a point where you are proficient with the tool. 

If you continue to write monolith programs, how do you learn to use the
ILE Call model and do functional decomposition? 

If you don't use SQL and push the limit, how do you learn to apply
concepts of relational databases? Of course, you don't. SQL is just not
a way to get data into a program. It is a way of thinking. 

Back to my previous point. If all you use is a hammer, the best solution
will always be a hammer.