Re: RunSQLStmt in production

Robert

I'm inclined to say that, since RUNSQLSTM is standard SQL, it will use whatever the optimizer chooses. It's nothing like OpnQryF that I can see, other than that both are CL commands.

I think that both RunSQLStm (no T on the end) and RunSql can be used in production - this would be just like running something like and INSERT or UPDATE in embedded SQL in RPG or COBOL or REXX. Same for RunSql. One difference with the latter - no spooled file output, IIRC.

When working at RJS, I used their own xxxSQL command in lots of places in the product. It used a generic QMQRY to run anything that could be run in STRSQL, including SELECT statements.

QMQRYs still have another advantage - substitution variables. You can, of course, build the SQL statement with variable data and use RUN SQL nicely - not so with RUNSQLSTM, which uses a source member.

I agree - RUNSQLSTM is recommended for building SQL objects - I used it to recreate, if needed, UDFs and stored procedures, as I recall, when a restore seemed to lose track of something.

HTH
Vern

On 3/29/2013 7:31 AM, Robert Clay wrote:

Thanks for the input, everyone.

The consensus seems to be that RunSQLStmt is primarily a
developer's/development tool and not necessarily designed for inclusion
in production processes. Agreed?

Another question comes to mind, though: what about performance?

Does RunSQLStmt use the CQE or the SQE? I'm assuming that it would fall
under the same limitations as a standard SQL statement in regards to the
optimizer determining which engine to use but I seem to recall that
RunSQLStmt was like OpnQryF in that it automatically got shuttled to the
CQE. Can anyone categorically confirm/deny?