Re: lazy, /dumb or inept programmer

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