Joe,

Your concerns about subselects and the ilk apply both to OPNQRYF and to
SQL.  Therefore they are of no assistance in choosing between one or the
other.  Most of the questions people have about SQL are not how to use a
cursor, but more related to issues that might pertain to both OPNQRYF and
SQL, such as subselects and what not.

Yes, I did mean the cursor solution.  I don't find using a cursor any big
deal.  And frankly, doesn't the debate often pop up of whether or not you
need to do a SETLL before a READ?



Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "Joe Pluta"
                    <joepluta@PlutaBrot       To:     <midrange-l@midrange.com>
                    hers.com>                 cc:
                    Sent by:                  Fax to:
                    midrange-l-admin@mi       Subject:     RE: RE: Can you do 
this in SQL
                    drange.com


                    01/30/2002 10:23 AM
                    Please respond to
                    midrange-l






> From: rob@dekko.com
>
> 2)  Joe, There is no such thing as a one line OPNQRYF.  You need
> the OVRDBF
> and the rest of the kludge.  New people find SQL easy to use.  OPNQRYF's
> crud about FILE vs. FORMAT, and which one do you declare in your RPG
> program is for people who need a testosterone rush, and this does it for
> them.

You're right, sort of.  OPNQRYF requires an OVRDBF.  Dunno what else you're
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
since.

You're opinion about new people finding SQL easy to use is just that, by
the
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, the rules seemingly arbitrary, the syntax obscure.  Once you
get
past a simple SELECT or UPDATE, and have to start dealing with subselects
and outer joins, many people get lost.  Far more people than get lost
chaining to a logical file.


> 3)  I think Alexei's solution was the most simple and straight forward.

Which solution?  The poor performing SQL or the open/close cursor, which
basically mimics RPG, only doesn't perform as well?  It's people who insist
on coding SQL FETCH loops really make me wonder.  RPG is designed for this
sort of processing; why add the overhead and obscurity of SQL syntax?  Once
you start using a cursor, the only real difference between SQL and native
I/O, when it comes down to it, is that with SQL you don't have to figure
out
your database paths ahead of time.  And in many situations you can address
that with OPNQRYF.

Anyway, I'm not going to convince anyone who thinks a cursor fetch beats a
READE loop or a primary file read.  If you think SQL is a better answer
than
RPG, then you have a completely different worldview than me anyway.

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.







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