×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 28 Mar 2013 21:08, Vernon Hamberg wrote:
RUNSQL has the same limitation as RUNSQLSTM - it will not run
a SELECT statement. I find being able to run a SELECT from a
command line to be so helpful, that I'll probably always keep
a command based on QMQRY for that purpose.
While the command interface to a *QMQRY to effect the request can be
nice, requesting the invocation of that CL request within the RUNSQLSTM
is not very nice IMO; too much escaping of apostrophes.
I would usually just encapsulate the SELECT in either a VIEW or a
CREATE TABLE ... AS and then issue a RUNQRY. Within a RUNSQLSTM by
invocation of the CL interpreter, either via the general request to CALL
QCMDEXC('RUNQRY ...', 00000000##.00000) or via a custom request to CALL
EXECCMD ('RUNQRY ...') to eliminate the 15P05 command-string length
parameter.
I had at one time utilized a private variation of the RUNSQL command
that would automatically encapsulate a given SELECT in that manner [as
described above; TABLE or VIEW in QTEMP], and then automatically issued
the CL request to the RUNQRY, followed by a DROP VIEW or DROP TABLE for
that which was created in QTEMP for use by the RUNQRY
QRYFILE((QTEMP/the_name)) request.
This mailing list archive is Copyright 1997-2024 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.
midrange.com
