Re: Query Fails In PHP db2_exec But Is Good in System I Navigator.

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