I always read your posts with interest, and normally I agree with (at
least most of) what you say, but I have to disagree here. Of course, we're
just talking about our opinions here, so there really isn't any  "right"
or "wrong", but in comparing SQL and OPNQRYF I think SQL wins hands down.
I think the reason you don't see many questions about OPNQRYF is that the
only people who use it any more are people who know it and are comfortable
with it -- no one else would go near it unless they were forced to, and
now that we  have SQL we don't have to. I have seen people create
single-use logical files just so they didn't have to use OPNQRYF, and I
have seen people spend hours trying to debug OPNQRYF statements.

OTOH, in fairness, I have also seen it used effectively, and I agree
completely that the main goal is to use the right tool for the right job.
I also agree that for record-by-record processing, SQL is a bad choice --
I'm 100% with you on that. But nowadays if I want to write a report that
allows a user to enter a few selection criteria and pick a sort order  and
then pulls data from, say, a transaction file and a couple of master
files, I'll pick embedded SQL over constructing a READ loop with multiple
CHAINs every time (and I used to do that rather than use OPNQRYF). I can
construct a simple statement (using PREPARE even allows me to construct it
on the fly), the performance is fine, and readability is largely
determined by how I format my statement (personally, I'm a big fan of
groupings, indents, etc.).

I think the reason we see so many questions about SQL is that a lot of
people see its potential and they're trying to learn it. The same thing
happened with RPGIV -- remember all the discussions of EVAL and BIFs and
string handling and all the other goodies? Another factor is people trying
to push things to the limit -- IMHO, the quest for the "single SQL
statement" is often more of a puzzle-solving exercise than a practical
solution to an actual problem (but I like puzzles, and I have learned a
lot from them :-). And let's not forget career enhancement -- SQL is used
in an awful lot of places, and should (heavens forbid!) the supply of RPG
programming jobs dry up in my area  I'd like to have _something_ other
than my boyish good looks to recommend me to another employer. . . . ;-)

Is SQL syntax arbitrary and obscure? Well, I think that depends on one's
point of view and experience -- if you've never seen it before, the answer
is probably "yes", but how is that different from RPG, CL, OPNQRYF, C,
Java or any other programming or database-management language? (Or for
that matter, any language at all?) Once you get used to it, it makes a lot
more sense, but that takes time and effort. Personally, I think SQL is
pretty understandable -- it's certainly possible to write obscure
statements, but then it's also possible to write obscure RPG programs, so
I don't really think that counts as a failing. . . .


Joe Pluta writes:
>You're right, sort of.  OPNQRYF requires an OVRDBF.  Dunno what else
>referring to.  As to file vs. format, I've never had a problem figuring it
>out.  Guess I read the manual at the beginning and it stuck with me ever
>You're opinion about new people finding SQL easy to use is just that, by
>way, and isn't supported by the facts.  Check the forums and see how many
>questions people ask about how to get SQL to work as opposed to how many
>questions are asked about logical files or even OPNQRYF over the years.
>You'll find that for many people, SQL is confusing and difficult to
>understand . . .

Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 by 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.