Jonathan Ball wrote:
No /WAY/ is OPNQRYF more integrated into RPG than SQL. IBM
basically abandoned OPNQRYF back when it was still called the
AS/400, and with good reason. If you think in database terms,
SQL is it. Database functionality evolves almost in lockstep
with SQL.
<<SNIP>>
rob@xxxxxxxxx wrote:
You think OPNQRYF is easy?! Shudder! I got tired of counting
apostrophes and whatnot long ago. Never used OPNQRYF again
after using embedded sql.
Tom Deskevich wrote:
<<SNIP>>
I know just learning embedded SQL I became somewhat
frustrated, knowing how easy it is with OPNQRYF. And
regardless of the enhancements, OPNQRY still seems to be
more integrated into RPG than SQL. <<SNIP>>
While I agree about using SQL versus OPNQRYF, I still offer...
Embedded SQL and dynamic SQL are no more integrated _into_ the
RPG than OPNQRYF. Both CL and SQL are separate /languages/ that
enable additional means of database access within the RPG. Although
the SQL is a language which can have statements placed into another
HLL language, the invocations are either via API or are effected
only with the use of a pre-compiler [as a method of generating API
calls equivalent to the statements]. Although the CL has no
pre-compiler feature for use within another HLL, the use of the
Control Language can also be accessed by API calls; i.e. commands
[CL "statements"] placed into another HLL.
However the CL is a language which provides the OPNQRYF which
creates an ODP. The RPG language actually has native
statements\opcodes that can access an ODP directly, without any
foreign language being embedded; i.e. no source directives are
required to notify of the utilization of upcoming non-RPG requests.
Of course actions must precede the RPG utilization, to both create
and make available the ODP to the RPG program, prior to consumption;
e.g. by READE. Contrast that with SQL for which there is no similar
ability of preparing an ODP other than the CREATE of a database
file. Yet that is not any better than CL since that feature allows
that via CRTPF, CRTLF, RSTOBJ, or CRTDUPOBJ. And the RPG can /READ/
the ODP, but the RPG can not /READ/ the SQL SELECT [except when
encapsulated in a VIEW or (non-EVI) INDEX as the database file]; of
the SQL, the RPG can only /READ/ an ODP created by open of a VIEW,
TABLE, or INDEX.
Because the native opcodes are utilized, the interface to the DB
is effectively unchanged when using OPNQRYF. However contrast that
with the SQL for which there are entirely different: set of error
codes; method of error handling those conditions; method of record
I\O. So which one really, is any more integrated _with_ RPG than
the other?
FWiW I had always desired that an SQL SELECT statement as dynamic
or embedded SQL could be issued with i-specific syntax to directly
generate a shared ODP in an HLL, and then operate much the same as
an OPNQRYF. This for example, as a new SQL CREATE:
CREATE ODP MYODP AS ( SELECT DBXFIL,DBXATR,DBXRDL FROM
QSYS/QADBXREF WHERE DBXLNK='P' AND DBXLIB='MYLIB' ORDER BY DBXRDL
DESC OPTIMIZE FOR ALL ROWS FOR READ ONLY WITH NC )
As it is now, one can replace the imaginary CREATE ODP statement
with the real CREATE VIEW statement, but that still requires an
OPNQRYF to establish the effects of the clauses from & after the
ORDER BY, and whatever means of sharing the ODP that was created
prior to the OPEN by the RPG.
Regards, Chuck
midrange.com
