RE: RUNSQLSTM 80 byte limit question

["DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>]

Dale!  <vbg>  Nice to see you again....

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



-----Original Message-----
From: Dan Bale [mailto:dbale@xxxxxxxxxxxxx]
Sent: Tuesday, June 22, 2004 8:51 AM
To: Midrange Systems Technical Discussion
Subject: RE: RUNSQLSTM 80 byte limit question


> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx / Vern Hamberg
<snip>
> 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

Good point, Vern.

I look at "long, strung-out (unstructured) SQL statements" as an invitation
to shoot one's self in the foot.  There have been numerous times that I have
had to "format" embedded SQL, extended Calc specs, and CL just so that it
would be somewhat human-readable.

Just wish there was a way to automagically do it.  It's usually a
rarely-used command that I'll invoke the prompter to fill in the parms;
otherwise I just type it all in myself.

db

--
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.