Re: RUNSQLSTM 80 byte limit question -- MIDRANGE-L

Hi Jim

Your RUNSQLSTM example will not have a problem, because no single line is longer than 80 characters. Newlines are considered white space, just as in all the other contexts for specifying SQL statements.

Isn't that the pits, the restriction on SELECT in RUNSQLSTM?

Good point about the prepare, I'd forgot about that. We've done the same kind of thing in C. But I think that does not work if you use host variables. And is necessary if you need to put in variable data in places that do not allow host variables. Oy!

I assume that building the string could be done in a /free block, so you'd have the entire width (100 characters) in which to put the various clauses. I still recommend pretty-print SQL. <g>

Later
Vern

At 08:00 AM 6/22/2004, you wrote:

i had no problem with this runsqlstm example:
0001.00 -- this is a comment
0002.00 update asapfile2/ioedet set odpart = 'TESTING PART'
0003.00 where odcono = 84 and odcusn = 'FRED '

Not all sql statements allowed (like Select)
multiple sql statements require a semicolon (;) between statements

Also in RPGLE, you can build your whole string (like 512a or more)
C* PREPARE VARIABLE S1 FOR THE BUILT STRING "STR"
C*
C/EXEC SQL
C+   PREPARE S1 FROM:STR
C/END-EXEC
C* SET THE CURSOR
C/EXEC SQL
C+   DECLARE C1 CURSOR FOR S1
C/END-EXEC
C/EXEC SQL OPEN C1
C/END-EXEC
jim


----- Original Message -----
From: "Vern Hamberg" <vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, June 22, 2004 8:28 AM
Subject: Re: RUNSQLSTM 80 byte limit question


> Not as far as I know, Mark. I just tried a SRC PF with RCDLEN(112) and it
> failed, showing only the first 80 characters.
>
> QMQRY is worse - the limit is 79. And embedded SQL in RPG IV is even worse
> - 73 characters - as the comment portion is not included. (Can you put
> embedded SQL inside /free blocks?) You have to use C to get a choice of
> record width - check out the CRTCQLCI command, which lets you specify the
> source width for SQL statements.
>
> But this raises another matter in my mind, viz., long, strung-out SQL
> statements vs. shorter, formatted statements. SQL, being unstructured and
> containing all kinds of processing in one statement (similar to nesting
> function calls in C but not often recommended) is hard enough to
> understand, to see what is going on. It really helps me to separate the
> various clauses to different lines, to put column names on separate lines,
> to align opening and closing parentheses vertically, to use some
indenting,
> etc. This all is aimed at clarity. It also means that I don't use long
> lines much. Sort of like pretty-print for program code.
>
> HTH
> Vern
>
> At 06:36 AM 6/22/2004, you wrote:
> >Does anyone know how to make RUNSQLSTM recognize more than 80 bytes per
line
> >or another command to use (perhaps within STRSQL) to read a longer source
> >command record.
> >
> >Mark Villa in Summerville SC
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.