Chuck,
Your suggestion to
"Review the variable\data in hex. Likely a character at\near that position 14 is not a 0x40."
lead me to discover that the three blanks between "PLTLCD" and "SET" were actually two nulls and a blank (x'000040').
That might explain sql's objection to the syntax at position 14...
Further investigation revealed that sql statement was built using a %trim(filename), where filename was loaded with a file name passed in from a CLP via a PLIST. The culprit was the calling CLP that defined the passed file name parm as 6 characters. The receiving PARM field was actually 8A. Fixing the definition in the calling CLP made it work fine.
Ya gotta love nuance!
Thanks for the clues.
-- Michael
~~~~~~~~~~~~~~~
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, February 13, 2012 6:27 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: SQL problems SQLSTATE 42601 - 104 on Execute Immediate
On 13-Feb-2012 15:03 , Koester, Michael wrote:
On 13-Feb-2012 14:19 , Koester, Michael wrote:
<<SNIP>>
UPDATE PLTLCD SET LCDSCM = 'ADSL Dynamic 0004780533 '
WHERE substr(LCDSCM, 6, 23)
<<SNIP>>
Chuck, SQLER5 is 14.
There are two spaces between the "PLTLCD" and "SET", and the second
space is at position 14 in the string.
Is that a problem?
My e-mail reader presented three blanks from the text that was
pasted. No matter...
Any amount of _true_ /white space/ is moot.
Review the variable\data in hex. Likely a character at\near that
position 14 is not a 0x40.
FWiW: Missing blanks after apostrophe as string delimiters and
literal lengths for syntax checking are also moot. What could have been
an issue for the given string was for the use of the "substr" scalar,
*if* the statement environment had SET OPTION for decimal separator as a
comma instead of a period; but that SUBSTR() was properly formed with
the extra space following each comma, to prevent a syntax error,
irrespective of decimal point choice\setting.
Regards, Chuck
midrange.com
