PDO->fetchAll() returns empty array on remote server

Question

Basically, on my localhost everything works fine. these are the php versions of both environments:

development (localhost) : 5.5.3

production: 5.3.27

I've been looking around quite some time to find a compatibility issue with no luck, this is kinda my last resort.

code snippet which returns the requested data in development but not in production:

function dbq($query, $array = array()) {
        $core = Core::getInstance();
        $STH = $core->dbh->prepare($query);
        $sth = $STH->execute($array);
        $res = $STH->fetchAll(PDO::FETCH_OBJ);
        print_r($res);
}

the connection is established successfully before, so there are no issues there. As I've stated before '$res' returns empty arrays in production environment.

The function is called by other functions, an example of this is:

function first() {
    return $this->dbq("SELECT * FROM $this->class 
               ORDER BY id ASC LIMIT 1");       
}

note: the second parameter is used for prepared statements, and is not always necessary.

-1 for the second function which is prone for injection and spoiling the very idea of PDO prepared statements — Your Common Sense, Apr 07 '14 at 18:58
why you're setting PDO::FETCH_OBJ twice? Are you sure once is not enough? — Your Common Sense, Apr 07 '14 at 18:59
I hear your concern, but this function is not influenced by user input. (users will never be able to put a parameter to this function) — Rebirth, Apr 07 '14 at 19:00
One NEVER can tell which can be influenced and which is not. Some projects grows, up to the point where more developers joined and one cannot control their actions. Such a function have to be error-proof WITHOUT any silent considerations — Your Common Sense, Apr 07 '14 at 19:02
fair point. Will get to it. Still no actual info about my real problem :/ — Rebirth, Apr 07 '14 at 19:21

score 1 · Accepted Answer · edited May 23 '17 at 12:21

1

You may debug your statement using $STH->debugDumpParams(). (documentation)

edit: the issue was due to MySQL column name case sensitivity or insensitivity, depending on the OS. (reference)

edited May 23 '17 at 12:21

Community

1
1

answered Apr 07 '14 at 19:38

Gras Double

15,901
8
56
54

Thank you so much for that, it didn't even occur to me that it would escape that in the older version :) – Rebirth Apr 07 '14 at 19:40
call it what you want, something was indeed wrong with '$this->class' hard coding it fixed my issue, gotta find a way around. – Rebirth Apr 07 '14 at 19:44
Interesting. So for some reason, the older PHP didn't recognize the `$this->class` as a class property. You may try `{$this->class}` or string concatenation. – Gras Double Apr 07 '14 at 19:51
no, found the real issue... apologies for the confusion... it appears that newer versions of php or mysql (not entirely sure which one) don't make a fuss about case sensitivity. It appears that $this->class was returning an uppercased class (User) while the table was in lowercase (user). Sorry for the inconvenience and thank you again for partially helping me solve the problem :) – Rebirth Apr 07 '14 at 19:53

score 0 · Answer 2 · answered Jul 15 '14 at 14:54

0

you are in upper/lower case mistake:

$STH = $core->dbh->prepare($query);
$sth = $STH->execute($array);

Isn't same $sth and $STH

answered Jul 15 '14 at 14:54

Mork

365
5
18

appreciate the help, my problem is already solved and this issue has also been solved in my code :) thank you for the input though! – Rebirth Jul 20 '14 at 19:57

PDO->fetchAll() returns empty array on remote server

2 Answers2