On 04-Dec-2015 12:00 -0600, Rob wrote:
I did notice that when I created the tables in SiN...(Sounds funny)
<<SNIP>>
iNav is used in the common vernacular of IBM i
I have changed single quotes to double quotes... Still NO JOY!
No joy would come from changing _every_ apostrophe in the expression
to a double-quote; if that was what was done.
AIUI, the suggestion was to change the delimiter for the PHP string
only; i.e. what was noted was that Mike had «changed the outer quote
<sic> to ""». Perhaps clearer, «changed the outer apostrophes used as
delimiters for the PHP string, to use instead, the double-quotes as
delimiters for the PHP string; i.e. from '…' to "…", whereby the
ellipsis character between the changed delimiters represents all of the
enclosed characters that remained unchanged»
Thus the implication was to change the given, shown in the first
bullet below, to what is shown in the second bullet below; noting only
the /outer/ two apostrophe characters were changed to be double-quote
characters:
• $sQry = 'SELECT ID FROM FINAL TABLE( INSERT INTO MyLibrary.zTest (
METHOD, AGENT, IP ) VALUES ( 'GET', 'Mozilla/5.0 (Windows NT 10.0;
WOW64;rv:42.0) Gecko/20100101 Firefox/42.0', '76.187.52.97' ) ) ;' ;
• $sQry = "SELECT ID FROM FINAL TABLE( INSERT INTO MyLibrary.zTest (
METHOD, AGENT, IP ) VALUES ( 'GET', 'Mozilla/5.0 (Windows NT 10.0;
WOW64;rv:42.0) Gecko/20100101 Firefox/42.0', '76.187.52.97' ) ) ;" ;
I infer that the following already is understood, and that at issue,
is probably a case of overlooking the obvious; offered anyhow:
Such revisions are required generally for when a common delimiter is
used for both the string(s) embedded within another string [the outer
string]; the change to the string specifications is made so the
parser(s) of the strings can /understand/ the intended meaning for the
input. Typically if either string-notation supports an alternative
delimiter, then that alternative form should be used for either the
outer string or the inner string(s). Otherwise either the inner-strings
must be /escaped/ with the escape character supported by the parser of
the inner-string, or the inner-strings have to be /escaped/ with an
escape character supported by the parser of the outer-string so the
parser of the outer-string knows that the following character is not
supposed to be interpreted as an end-of-string.
<<SNIP>>
midrange.com
