Re: SQL naming issue from PHP - Debug?

SOLVED

I figured out the issue. It wasn't a naming issue. Something was
sanitizing the SQL. There was a "...cut..." in my SQL statement.
Initially I thought the logging mechanism was truncating the log entry due
to length, but it turns out the "...cut..." web being injected into the
actual SQL statement. I figured out how to adjust the syntax so the SQL
statement executed without alteration. Whatever messed with the SQL did
not like a carriage return/line feed in my SQL statement. Those characters
were only there to make the SQL more legible in the source, so I just
removed the characters. The statement started working again after the
carriage return / line feed was removed.

The thing is, this was not a new program and this started happening out of
nowhere. I really don't know where the SQL was being altered. No search
engines seem to index periods, so I cannot search "...cut..." and find out
what might have added that.

The error occurred in db2_prepare and the exact error message was
"SQLSTATE=42601 SQLCODE=-104 Token . was not valid. Valid tokens: ( + - ? :
DAY INF NAN NOT RID ROW RRN CASE CAST CHAR DATE DAYS. "

Adding all this information to the thread in hopes that someone might
stumble across this if they run in to the same issue.


On Fri, Oct 2, 2015 at 11:43 AM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 02-Oct-2015 09:03 -0600, Matt Lavinder wrote:

I am having an issue all of a sudden where one of my PHP
applications seems to have switched to system naming for SQL
statements.

<<SNIP>>

Is there a way to pull SQL connection information so I can check
when system naming is getting turned on? I cannot seem to get
db2_get_option to work for i5_naming. It keeps returning "false"
which means the call failed.

I'd prefer to get the information using a PHP function (for
consistency), but I'll pull it using an SQL statement if I have to.

I'd hate using a test statement like "select * from qsys2/sysdummy1",
but it is the only option I have at the moment. It just feels like I
am probably missing something.

FYI...I am using persistent connections.

Disregarding the PHP aspect, FWiW:

For a lack of a CURRENT NAMING special-register in the SQL, in a SQL
REXX procedure I ended up using effectively that /test statement/ approach,
then testing for the condition of sqlcode=-5016 [aka SQL5016].

FWiW: My procedure was processing a generic DROP, so if my Naming option
did not match the qualifier included in the input-string-as-object-name for
the DROP statement, then I just overrode the qualifier and re-issued the
DROP statement; i.e. there was no separate /test statement/ being
performed. If I had to perform a separate statement, then the choice would
have been to use a statement doing anything but a query and using an
improbable name like "testFor"/"namingIs" rather than a known-to-exist
object name; a near-immediate -204 [thus also no /long/ name used] is
likely much cheaper than accomplishing any work [and disposal of that work;
such as a successful query] against a valid object.

--
Regards, Chuck


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