MySQL/ADODB case sensitivity

Permalink
I'm scripting out building some pages, and I'm seeing some inconsistent behavior which I'm having a hard time tracking down. For example, in one of my scripts while calling $page->addBlock I'm getting a failure on what is evidently a case sensitivity issue (the database wants CamelCased column names but the active record only contains lower cased column names). However, this works fine in another script. So whether it works or not seems dependent on the execution path.

In both cases I've set ADODB_ASSOC_CASE to 2 via define and as a global variable.

So my question is, are there any other environment settings or aspects of global state that affect this, besides ADODB_ASSOC_CASE?

System is a Linux virtual machine.

 
jordanlev replied on at Permalink Reply
jordanlev
Setting ADODB_ASSOC_CASE to 2 should be all you need. *BUT* if you created the database before you changed that setting, then it does not apply to any existing tables. Also if you copied the database over from another machine that didn't have that setting, it won't be changed either.

Try this utility to fix it:
https://github.com/ahukkanen/c5_db_case_sensitivity...

Also see these threads:
http://www.concrete5.org/community/forums/installation/transfert-of...
http://www.concrete5.org/community/forums/customizing_c5/problem-go...
xaritas replied on at Permalink Reply
Thanks for your reply, I figured it out though.

The issue was that my library code is name spaced. When I invoked the code from a driver that was not name spaced, it worked fine, but if I moved the driver into the namespace, the assignment to $ADODB_ASSOC_CASE was no longer in the global scope. I was under the impression that it was declared global during C5 initialization but that is not the case. In short, I fixed my problem with:

global $ADODB_ASSOC_CASE; // this line is the pixie dust
$ADODB_ASSOC_CASE = 2; // previously this all by itself worked


Evidently this sort of thing is obvious at 9:00 am but not at 9:00 pm.