RE: When should one use SQL/RPG?

[Mikael Salo <mikael.salo@xxxxxxx>]

Hi again!
Thank you for your answers. Basically you say that when dealing with a 
single record it is better
to do it with RPG. Fine, I can live with that. However, I'm not quite 
sure how the 'best choice'
an index is selected by the SQL engine. I've noticed that it will create 
an index of its own if it
doesn't suit the engine's purpose, even if I want the engine to use an 
particular index that exists.
More or less it says in the joblog that the cost is too expensive to use 
the existing one...but
that might be a question for an other forum...a database one I guess...

Now I want to add some more to the question. What about joining files to 
get one/several
record(s)? Is SQL a choice that can be considered or is RPG  still a 
better choice?

The reason I asked this question from the beginning was that I have some 
10-15 files that I
want to join (and from there scavenge data that fits some contitions). 
I've solved it by chaining
in several steps to get what I want. However, the code is not that easy 
to follow, even if
it is very neat as it is now (if I may say so myself). I started this 
task by prepared SQL
statements, but it was too slow. I changed the SQL statements to RPG and 
discovered
that I made an logical error that affected the effectivity of the 
program (i.e SQL or not,
the program was doomed as it was because of this, some re-design was done).

Since I've finished writing the program I see no point in 'converting' 
back to SQL but I'm still
curious if SQL would have been a good choice from the beginning. Easy to 
read/maintain
by my colleagues. They might learn something new also by using SQL since 
they're stuck in
the OPNQRYF way of life...nothing wrong in that but it is not my cup of 
tea you see...

Regards,

Mikael Salo