Re: RunSQLStmt in production

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

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?