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



Thanks Luis. I'm not at all familiar with iNav, (insufficient memory resources has kept me from exploring much there) but I did muddle my way into the "Run an SQL script" window where I pasted the contents of my source (comments and all), and clicked RUN ALL. It ran, and indicated: "Statement ran successfully (827 ms)".
No other diagnostics showed there, so I'm led to believe the defect is in the RUNSQLSTM process (which SysAdmin will be using to put my code into production).

-- Michael


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-
bounces@xxxxxxxxxxxx] On Behalf Of Luis Rodriguez
Sent: Wednesday, November 06, 2013 8:20 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Too many comments in QSQLSRC?

Michael, Alan:


FWIW, I have found that iNav's Run SQL Scripts option gives (IMHO) more
detailed error messages, with a better "pinpointing" of where the error
may be.

Regards,
Luis

Luis Rodriguez
IBM Certified Systems Expert - eServer i5 iSeries
--



On Wed, Nov 6, 2013 at 8:37 AM, Alan Cassidy
<ACassidy@xxxxxxxxxxxxxx>wrote:

That message has nothing to do with comments.

Somewhere in your 80 lines of code, your statement attempts to
calculate or concatenate a derived value (one computed from other
columns) and put the result into a new statement-defined column, like
a sub-query.

What I do with things like that is break it up into chunks you can
analyze one at a time. Even if my plan is to end up with a complex
80-line View, for example, if it includes a common table expression
(WITH clause), I define it as a temporary file of its own in QTEMP,
and then use that for the other one.

That way you find out where your problem is.

RUNSQLSTM creates a spool file that tells you where it is that SQL
thinks the error is. You might check that first. BUT I still suggest
the stepwise approach first, as you can more easily check the results
from each "discrete" part of the statement more easily.

--Alan


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Koester, Michael
Sent: Wednesday, November 06, 2013 7:40 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Too many comments in QSQLSRC?

(yet another episode in "Novice [mis]adventures in SQL") It seemed
like such a good idea to have my Create View coded up in its own
source member in QSQLSRC, so I could have that source member moved to
our production repository of code, and SysAdmin could create
production objects from that member with RUNSQLSTM.
And it also seemed reasonable that I could put a comment block at the
top of the source member where the next poor schmuck could "check
out"
the source and get a sense of the method to my madness before
laughing
at my code.

So I have this source member with a somewhat complex Create View
statement, running roughly 80 lines. My comment block was about 50
lines, including the updates history log structure, etc.

My RUNSQLSTM fails with a non-descript "Receiver value too small to
hold result." (MCH1210).

I rip out all but 3 of my comment lines, and everybody's happy - no
harm, no foul, no error. I thought about reinserting comments one by
one to find the exact threshold of doom, but didn't.

Is this documented somewhere, that while one might expect the
RUNSQLSTM to skip past any source line beginning with "--", that it
might tire of skipping and trip? I did try to wrap the whole comment
block thing in /* ... */, so it wouldn't have to deal with all the
dashes, but that didn't work either.

So it all goes to production with three lines of comments, one of
which
being:
-- Add more comments at your peril!

Running OS 7.1 here.
One other item of note: The MCH1210 did not prevent creating the LF
object, but experience from earlier this week tells me that when this
happens when SysAdmin runs the RUNSQLSTM, the production object is
flawed in some way, and fails to get created in a RSTLIB operation.

Michael Koester
Programmer/Analyst

DataEast



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.