Weird problem with PDO on production server

Okay, so I updated my code, and have been checking to see if everything works as expected, after changing PDO::ATTR_EMULATE_PREPARES to false.
On my test-server, running WAMP on Win 10, everything seems fine, but pushing the code to the test-server, I get an error on the after_setup-page, looking like this (after turning PDO::ATTR_ERRMODE => PDO::ERRMODE_WARNING on):

Warning: PDO:repare(): SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. in /home/3/c/cntrl/www/after_setup.php on line 47

This is the first error, which shows up after turning on the ATTR_ERRMODE.

Second error:
Fatal error: Call to a member function execute() on a non-object in /home/3/c/cntrl/www/after_setup.php on line 50

This one shows up regardless of whether or not the ERRMODE is on or not.

Okay - the first one has me a bit stumped, as I don't really see how that will trigger at all, but the second one, while I know why it might show, I don't understand why it shows here, but not on my test-server.

The query being run is something as simple as this:
$getgroups = $core->dbh->prepare("SELECT * FROM {$dbprefix}groups WHERE group_internal = 1 ORDER BY name");
var_dump'ing $getgroups locally returns the actual query.
var_dump'ing it on the production server gives me bool(false).
The weird thing is this - the table in the database has no data currently - but that should return just an empty result, right, even with emulated prepares off? And why does it work fine, no errors, on my local host, while throwing errors on the production server? Different versions of SQL and PHP, but nothing obviously different, as far as I can tell.

Any input?

EDIT: Turning ON emulated prepares fixes the errors, so I guess it might be the empty result set doing it, but I'm confused as to why it works on my local machine, but not on the server?

 

I'd have to see the actual code, though usually something like this happens when you have your DB connection in the incorrect scope to be called.

The "real " error there is the " Call to a member function execute() on a non-object" -- which means that your ->dbh isn't an object at that stage in the code.

Usually though if emulated prepares "fixes" something, there's something horribly wrong with the server configuration. Particularly given the amount of things it breaks (like multiple parameters for LIMIT)

Maybe the server is on some crappy outdated version of PHP? or outdated mySQL?

Another of the reasons I don't trust managed hosting.

 

As I said, the "fix" (turning emulated prepares on) fixes the issue, on the production server.
However, on my local server, it works just fine, either way. Hence I don't think it's anything to do with the query. Regardless, this could just as well just been a ->query, only reason I use prepare is to issue an execute to eventually catch errors - I might just redo it using only a query, see if that fixes the issue on the other server as well.

The server is running on PHP 5.5, so not that bad. I'm running 5.5.12 locally. However, the database is MariaDB - however, that shouldn't really matter, methinks? I'm running mySQL locally. Maybe I should test with a MariaDB-install locally as well, see if that still triggers the error.

A var_dump($dbh) returns object(PDO)#3 (0) { } so it seems the object exists.

 

But then again, on my local server, those warnings about buffered output doesn't show up either, so it might be something on the server. I'll contact customer support and see if they have anything to say, if not, I will start looking for another server somewhere

 

MariaDB is NOT as "compatible" with mySQL as they like to claim. I tried it not that long ago and much like desktop linux I take comfort in that it exists should the mainstream go awry, but it's REALLY not my first choice due to several shortcomings.