Re: SQL naming issue from PHP - Debug?

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.