On 12/22/2015 11:52 PM, Rob wrote:
My script creates the tables using Upper And Lower Case letters.
Based on the behaviour you describe, it doesn't...
I can run sql queries using any case.
...because the default behaviour of DB2 is to fold identifiers to upper
case. Which is what happened when you did the CREATE TABLE.
Why can the all powerful DB2 not return the field names as I created
them in the result set?
It can do exactly that.
All Caps is for dead head screamers. This is a new age of computing...
we have a SHIFT key!
I'd bet that the default action of folding to upper case is to preserve
compatibility with pre-existing code. Which answers the 'why'.
Took me a few minutes to figure out why I was not getting any data out
of a specific field. I used fetch_assoc and $aRow[ 'Name' ] rather than
$aRow[ 'NAME' ] .
I thought that 'i5_naming' => DB2_I5_NAMING_OFF was supposed to turn
that off.
What made you think that?
That's not snark, it's a real question. PHP is new enough to me that I
personally don't assume anything about it. Nothing. Not single vs
double quote, not case sensitivity, not anything. To resolve my many
questions, I look long and hard at the documentation, tutorials,
examples, and finally the results of my own code. The PHP documentation
for i5_naming is terse, but clear enough to me. But I'm very familiar
with DB2 for IBM i, so there's that.
Here is the documentation for i5_naming, taken from
http://php.net/manual/en/function.db2-connect.php
' DB2_I5_NAMING_ON value turns on DB2 UDB CLI iSeries system naming
mode. Files are qualified using the slash (/) delimiter. Unqualified
files are resolved using the library list for the job.
DB2_I5_NAMING_OFF value turns off DB2 UDB CLI default naming mode,
which is SQL naming. Files are qualified using the period (.) delimiter.
Unqualified files are resolved using either the default library or the
current user ID.'
The i5_naming makes no mention whatsoever of folding table, view, index,
or column names to upper case. It only mentions the library list and
the delimiter. Which is completely correct.
So, where did you get the idea that i5_naming affects case sensitivity?
If it's an example on the web, or documentation, or a wiki - we really
ought to correct it so that those who follow us aren't lead down the
same path.
This is probably just a rant with no solution.
I used to feel the same way about MySQL. I got burnt so often that I
had a sour feeling every time I had to use it for something. It turned
out that my burnt fingers were almost entirely due to my own
assumptions. I'd assumed that MySQL was DB2 with a regional accent, and
many of my baseline DB2 assumptions are not a good fit for MySQL.
I didn't get remotely good with MySQL until I'd shed this notion in my
own mind that MySQL was a toy made by some other tribe who clearly don't
understand databases, SQL, or decent documentation.
I'd like to share this hard-won personal lesson: Telling a MySQL guru
that his database software was crap was not the best way to get him to
help me. Mocking the documentation because it's written in an
unfamiliar style put me in a mindset to avoid the docs in favour of my
objectively false assumptions. Being snarky to the people who helped me
ended up alienating the only source of genuine help I was getting. In
short, I was sabotaging myself by pushing away the unfamiliar instead of
embracing it as something new to learn.
Don't be like me.
midrange.com
