Geek Answers Handbook

Disabling PDO :: ATTR_EMULATE_PREPARES causing an "unknown" problem

Just a quick question regarding the PDO attribute ATTR_EMULATE_PREPARES is simply to put, and left by default (true) everything works fine and dandy. However, turn it off and, well, I didn’t even receive a PHP error message, just a browser warning telling me that "the connection was reset".

For reference, here is a sample code that I used

<?php include_once("config.php"); try { $dbh = new PDO ( "mysql:host=". DB_SERVER .";dbname=" . DB_NAME, DB_USER, DB_PASS, array ( PDO::ATTR_PERSISTENT => true, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES => true ) ); } catch(PDOException $e) { echo "<pre>"; print_r("Error: " . $e); echo "</pre>"; die(); } $idNum = "1"; $sth = $dbh->prepare("SELECT * FROM `table` WHERE `id` = ?;"); $sth->bindParam(1,$idNum); $sth->execute(); $res = $sth->fetch(); ?> <pre> <?=print_r($res); ?> </pre>

Which pleasantly returns a query from my beautiful test pattern ...

 Array ( [id] => 1 [field1] => q12w3e4r5t6y7u8i9 [field2] => kijhgbfvcdoikujyh )

However, if I had the time to set the PDO :: ATTR_EMULATE_PREPARES value to false, it would simply fail and work again until I returned its original value. Is there anything I can do to find out what causes this, or am I missing something really simple?

My PHP version is currently 5.4.3 and MySQL is 5.5.24

+7
source share
4 answers

This looks like an error in some versions of PHP:

https://bugs.php.net/bug.php?id=61411

There seems to be a problem running both

 PDO::ATTR_PERSISTENT => true

and

 PDO::ATTR_EMULATE_PREPARES => true

What do you have in your array of PDO attributes / options.

+5
source

I had the same problem and I found two reasons why this could happen when ATTR_EMULATE_PREPARES = false:

  1. If the Select statement contains both AND / OR operands, the query may fail. I had to separate them into different requests.

  2. If the insert contains bindValue holders, ATTR_EMULATE_PREPARES = false is more stringent so that these holder names exactly match.

0
source

Hi, I figured out how to solve your problem (and mine).

I experienced the same problem, just a connection failure, no errors. For some reason, this does not work because you added the ATTR_EMULATE_PREPARES parameter to the PDO configuration array when you call the PDO database handler constructor, one way or another it will cause PDO to fail.

When you start the PDO database handler without the ATTR_EMULATE_PREPARES parameter and then use setAttribute to turn off emulation, it will work. Thus:

 // Configure PDO to really prepare statements and to not emulate them $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

For people who just read this and wonder why disable ATTR_EMULATE_PREPARES, if possible, read: how safe are the prepared PDO reports

-1
source

The MYSQL PHP driver does not actually support prepared statements; it has very poor performance. Disabling emulated statements for mysql can cause many errors.

I just hit my head on this subject a couple of days ago.

Have this:

public on the net grick dot 07-Mar-2012 04:23

With PDO_MYSQL, you need to remember the PDO :: ATTR_EMULATE_PREPARES option.

The default value is TRUE, for example $ Dbh-> SetAttribute (PDO :: ATTR_EMULATE_PREPARES, true);

This means that no prepared statement is created using the $ dbh-> prepare () call. When exec () is called, PDO replaces the placeholders with the values ​​itself and sends MySQL a common query string.

The first consequence is a call to $ dbh-> prepare ('garbage'); does not report an error. You will receive an SQL error during the operation of the $ dbh-> exec () call. The second is the risk of SQL injection in special cases, for example, using a placeholder for the table name.

The reason for emulation is the poor performance of MySQL with prepared statements. Emulation is much faster.

Source: User Tab .

-2
source

More articles:


All Articles