Hopefully this saves time for folks: one should use $count = $stmt->rowCount() after $stmt->execute() in order to really determine if any an operation such as ' update ' or ' replace ' did succeed i.e. changed some data.
Jean-Lou Dupont.
(PHP 5 >= 5.1.0, PHP 7, PHP 8, PECL pdo >= 0.1.0)
PDOStatement::execute — Executa ums instrução preparada
Executa a instrução preparada. Se a instrução preparada inclui marcadores de parâmetros:
PDOStatement::bindParam() e/ou PDOStatement::bindValue() devem ser chamadas para vincular variáveis ou valores (respectivamente) aos marcadores de parâmetros. Variáveis vinculadas passam seus valores como entrada e recebem o valor de saída, se houver, de seus marcadores de parâmetros associados
ou um array de valores de parâmetros, de entrada somente, deve ser passado
params
Um array de valores com tantos elementos quantos forem os
parâmetros vinculados na instrução SQL sendo executada.
Todos os valores são tratados como PDO::PARAM_STR
.
Valores múltiplos não podem ser vinculados a um parâmetro único; por exemplo, não é permitido vincular dois valores a um único parâmetro nomeado em uma cláusula IN().
Vincular mais valores que o especificado não é possível; se existirem mais chaves em
params
que no SQL especificado
em PDO::prepare(), a instrução
falhará e um erro será emitido.
Emite um erro de nível E_WARNING
se o atributo PDO::ATTR_ERRMODE
estiver definido
como PDO::ERRMODE_WARNING
.
Lança uma exceção PDOException se o atributo PDO::ATTR_ERRMODE
estiver definido como PDO::ERRMODE_EXCEPTION
.
Exemplo #1 Executa uma instrução preparada com variável e valor vinculados
<?php
/* Executa uma instrução preparada vinculando uma variável e um valor */
$calorias = 150;
$cor = 'ver';
$sth = $dbh->prepare('SELECT nome, cor, calorias
FROM frutas
WHERE calorias < :calorias AND cor LIKE :cor');
$sth->bindParam('calorias', $calorias, PDO::PARAM_INT);
/* Nomes podem ser prefixados com dois-pontos ":" também (opcional) */
$sth->bindValue(':cor', "%$cor%");
$sth->execute();
?>
Exemplo #2 Executa uma instrução preparada com um array de valores nomeados
<?php
/* Executa uma instrução preparada passando um array de valores de inserção */
$calorias = 150;
$cor = 'vermelha';
$sth = $dbh->prepare('SELECT nome, cor, calorias
FROM frutas
WHERE calorias < :calorias AND cor = :cor');
$sth->execute(array('calorias' => $calorias, 'cor' => $cor));
/* Chaves de array podem ser prefixadas com dois-pontos ":" também (opcional) */
$sth->execute(array(':calorias' => $calorias, ':cor' => $cor));
?>
Exemplo #3 Executa uma instrução preparada com um array de valores posicionais
<?php
/* Executa uma instrução preparada passando um array de valores de inserção */
$calorias = 150;
$cor = 'vermelha';
$sth = $dbh->prepare('SELECT nome, cor, calorias
FROM frutas
WHERE calorias < ? AND cor = ?');
$sth->execute(array($calorias, $cor));
?>
Exemplo #4 Executa uma instrução preparada com variáveis vinculadas a marcadores posicionais
<?php
/* Executa uma instrução preparada vinculando variáveis PHP */
$calorias = 150;
$cor = 'vermelha';
$sth = $dbh->prepare('SELECT nome, cor, calorias
FROM frutas
WHERE calorias < ? AND cor = ?');
$sth->bindParam(1, $calorias, PDO::PARAM_INT);
$sth->bindParam(2, $cor, PDO::PARAM_STR, 12);
$sth->execute();
?>
Exemplo #5 Executa uma instrução preparada usando array para cláusula IN
<?php
/* Executa uma instrução preparada usando um array de valores para uma cláusula IN */
$params = array(1, 21, 63, 171);
/* Cria uma string para marcadores de parâmetros preenchidas com o número de parâmetros */
$place_holders = '?' . str_repeat(', ?', count($params) - 1);
/*
Isto prepara a instrução com marcadores anônimos suficientes para cada valor
no array $params. Os valores do array $params são então vinculados aos
marcadores na instrução preparada quando ele é executada.
Isto não é a mesma coisa que usar PDOStatement::bindParam() já que isso
requer uma referência à variável. PDOStatement::execute() apenas vincula
por valor.
*/
$sth = $dbh->prepare("SELECT id, nome FROM contatos WHERE id IN ($place_holders)");
$sth->execute($params);
?>
Nota:
Alguns drivers requerem que o cursor seja fechado antes que a próxima instrução seja executada.
Hopefully this saves time for folks: one should use $count = $stmt->rowCount() after $stmt->execute() in order to really determine if any an operation such as ' update ' or ' replace ' did succeed i.e. changed some data.
Jean-Lou Dupont.
Note that you must
- EITHER pass all values to bind in an array to PDOStatement::execute()
- OR bind every value before with PDOStatement::bindValue(), then call PDOStatement::execute() with *no* parameter (not even "array()"!).
Passing an array (empty or not) to execute() will "erase" and replace any previous bindings (and can lead to, e.g. with MySQL, "SQLSTATE[HY000]: General error: 2031" (CR_PARAMS_NOT_BOUND) if you passed an empty array).
Thus the following function is incorrect in case the prepared statement has been "bound" before:
<?php
function customExecute(PDOStatement &$sth, $params = NULL) {
return $sth->execute($params);
}
?>
and should therefore be replaced by something like:
<?php
function customExecute(PDOStatement &$sth, array $params = array()) {
if (empty($params))
return $sth->execute();
return $sth->execute($params);
}
?>
Also note that PDOStatement::execute() doesn't require $input_parameters to be an array.
(of course, do not use it as is ^^).
An array of insert values (named parameters) don't need the prefixed colon als key-value to work.
<?php
/* Execute a prepared statement by passing an array of insert values */
$calories = 150;
$colour = 'red';
$sth = $dbh->prepare('SELECT name, colour, calories
FROM fruit
WHERE calories < :calories AND colour = :colour');
// instead of:
// $sth->execute(array(':calories' => $calories, ':colour' => $colour));
// this works fine, too:
$sth->execute(array('calories' => $calories, 'colour' => $colour));
?>
This allows to use "regular" assembled hash-tables (arrays).
That realy does make sense!
When using a prepared statement to execute multiple inserts (such as in a loop etc), under sqlite the performance is dramatically improved by wrapping the loop in a transaction.
I have an application that routinely inserts 30-50,000 records at a time. Without the transaction it was taking over 150 seconds, and with it only 3.
This may affect other implementations as well, and I am sure it is something that affects all databases to some extent, but I can only test with PDO sqlite.
e.g.
<?php
$data = array(
array('name' => 'John', 'age' => '25'),
array('name' => 'Wendy', 'age' => '32')
);
try {
$pdo = new PDO('sqlite:myfile.sqlite');
}
catch(PDOException $e) {
die('Unable to open database connection');
}
$insertStatement = $pdo->prepare('insert into mytable (name, age) values (:name, :age)');
// start transaction
$pdo->beginTransaction();
foreach($data as &$row) {
$insertStatement->execute($row);
}
// end transaction
$pdo->commit();
?>
[EDITED BY sobak: typofixes by Pere submitted on 12-Sep-2014 01:07]
Strangely the manual doesn't give a full SELECT example.
<?php
$sql = <<<SQL
SELECT ALL name, calories, colour
FROM fruit
WHERE calories < :calories AND colour = :colour
SQL;
$select = $pdo->prepare($sql);
$select->execute(['calories' => 150, 'colour' => 'red']);
$data = $select->fetchAll();
When passing an array of values to execute when your query contains question marks, note that the array must be keyed numerically from zero. If it is not, run array_values() on it to force the array to be re-keyed.
<?php
$anarray = array(42 => "foo", 101 => "bar");
$statement = $dbo->prepare("SELECT * FROM table WHERE col1 = ? AND col2 = ?");
//This will not work
$statement->execute($anarray);
//Do this to make it work
$statement->execute(array_values($anarray));
?>
"You cannot bind more values than specified; if more keys exist in input_parameters than in the SQL specified in the PDO::prepare(), then the statement will fail and an error is emitted." However fewer keys may not cause an error.
As long as the number of question marks in the query string variable matches the number of elements in the input_parameters, the query will be attempted.
This happens even if there is extraneous information after the end of the query string. The semicolon indicates the end of the query string; the rest of the variable is treated as a comment by the SQL engine, but counted as part of the input_parameters by PHP.
Have a look at these two query strings. The only difference is a typo in the second string, where a semicolon accidentally replaces a comma. This UPDATE query will run, will be applied to all rows, and will silently damage the table.
<?php
/**
* Query is intended to UPDATE a subset of the rows based on the WHERE clause
*/
$sql = "UPDATE my_table SET fname = ?, lname = ? WHERE id = ?";
/**
* Query UPDATEs all rows, ignoring everything after the semi-colon, including the WHERE clause!
*
* Expected (but not received):
*
*** Warning:
*** PDOStatement::execute():
*** SQLSTATE[HY093]:
*** Invalid parameter number: number of bound variables does not match number of tokens...
*
*/
// Typo here ------------------------ |
// V
$sql = "UPDATE my_table SET fname = ?; lname = ? WHERE id = ?"; // One token in effect
$pdos = $pdo->prepare($sql);
$pdos->execute( [ 'foo', 'bar', 3 ] ); // Three input_parameters
?>
PHP 5.4.45, mysqlnd 5.0.10
simplified $placeholder form
<?php
$data = ['a'=>'foo','b'=>'bar'];
$keys = array_keys($data);
$fields = '`'.implode('`, `',$keys).'`';
#here is my way
$placeholder = substr(str_repeat('?,',count($keys)),0,-1);
$pdo->prepare("INSERT INTO `baz`($fields) VALUES($placeholder)")->execute(array_values($data));
If your MySQL table has 500,000+ rows and your script is failing because you have hit PHP's memory limit, set the following attribute.
<?php $this->pdo->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, false); ?>
This should make the error go away again and return memory usage back to normal.
I have found very strange behavior for PostgreSQL:
Outside of a transaction, you can pass boolean true/false as members of the input array and it seems to work.
However, *inside* a transaction, boolean true works but boolean false does not. Instead, pass something "falsey" like integer 0 or string "false"
It seems, that the quoting behaviour has changed somehow between versions, as my current project was running fine on one setup, but throwing errors on another (both setups are very similar).
Setup 1: Ubuntu 6.10, PHP 5.1.6, MySQL 5.0.24a
Setup 2: Ubuntu 7.04, PHP 5.2.1, MySQL 5.0.38
The code fragment which caused problems (shortened):
<?php
$stmt = $pdo->prepare("SELECT col1, col2, col3 FROM tablename WHERE col4=? LIMIT ?");
$stmt->execute(array('Foo', 1));
?>
On the first Setup this executes without any problems, on the second setup it generates an Error:
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''1'' at line 1
The problem is, that $stmt->execute() quotes the number passed to the second placeholder (resulting in: ... LIMIT '1'), which is not allowed in MySQL (tested on both setups).
To prevent this, you have to use bindParam() or bindValue() and specify a data type.
When you try to make a query with a date, then take the whole date and not just a number.
This Query will work fine, if you try it like this:
SELECT * FROM table WHERE date = 0
But if you try it with prepared you have to take the whole date format.
<?php
$sth = $dbh->prepare('SELECT * FROM table WHERE date = :date');
$sth->execute( $arArray );
//--- Wrong:
$arArray = array(":date",0);
//--- Right:
$arArray = array(":date","0000-00-00 00:00:00");
?>
There must be something with the mysql driver.
best regards
T-Rex
If one parameter name is missing or misspelled, this function throws an error of level E_WARNING, even when PDO::ATTR_ERRMODE is set to PDO::ERRMODE_SILENT!
In the same situation, but when PDO::ERRMODE_WARNING is set, this function throws TWO errors of level E_WARNING!
This function does not throw any error when PDO::ERRMODE_EXCEPTION is set, instead, it throws a PDOException.
All this applies even when you use PDOStatement::bindParam() function with misspelled parameter name and than use PDOStatement::execute();
Tested on: Windows 10, PHP 5.5.35, mysqlnd 5.0.11, MySQL 5.6.30.
<?php
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT);
$colour = 'red';
$sth = $dbh->prepare('SELECT name, colour, calories
FROM fruit
WHERE colour = :colour');
/*
Notice the parameter name ':color' instead of ':colour'.
When PDO::ERRMODE_SILENT is set, this function throws the error:
Warning: PDOStatement::execute(): SQLSTATE[HY093]: Invalid parameter number: parameter was not defined in...
When PDO::ERRMODE_WARNING is set, this function throws this two errors:
Warning: PDOStatement::execute(): SQLSTATE[HY093]: Invalid parameter number: parameter was not defined in...
Warning: PDOStatement::execute(): SQLSTATE[HY093]: Invalid parameter number in...
*/
$sth->execute(array(':color' => $colour));
?>
It took me a long while to realize this and the documentation didn't seem very clear on using PDO_Statement::execute() on a SELECT statement type query, so I wanted to note this here. When preparing a SELECT query and then executing it using PDO_Statement::execute(), you can then simply proceed to use PDO_Statement::fetch() or PDO_Statement::fetchAll() on that same PDO_Statement object. This is no different than using PDO::query() to return a PDO_Statement object, and then calling PDO_Statement::fetch() on that object. This is because the PDO_Statement object is of course still a PDO_Statement object, and, as the PDO::query documentation (https://www.php.net/manual/en/pdo.query.php) says, PDO::query also "[p]repares and executes an SQL statement."
<?php
$pdo_statement = $my_pdo_object->prepare( "SELECT * FROM `MyTable` WHERE `Field1` = 'this_string'" );
if ( true === $this->execute_safe_query( $pdo_statement ) ) {
echo $pdo_statement->fetch();
}
?>
Note: Parameters don't work with a dash in the name like ":asd-asd" you can do a quick str_replace("-","_",$parameter) to fix the issue.
If you are having issues passing boolean values to be bound and are using a Postgres database... but you do not want to use bindParam for *every* *single* *parameter*, try passing the strings 't' or 'f' instead of boolean TRUE or FALSE.
If you're going to derive PDOStatement to extend the execute() method, you must define the signature with a default NULL argument, not an empty array.
In otherwords:
<?php
class MyPDOStatement extends PDOStatement {
// ...
// don't use this form!
// function execute($input_parameters = array()) {
// use this instead:
function execute($input_parameters = null) {
// ...
return parent::execute($input_parameters);
}
}
?>
As a sidenote, that's why I always set default parameter to NULL and take care of handling the actual correct default parameters in the body of the method or function. Thus, when you have to call the function with all the parameters, you know to always pass NULL for defaults.
As of 5.2.6 you still can't use this function's $input_parameters to pass a boolean to PostgreSQL. To do that, you'll have to call bindParam() with explicit types for each parameter in the query.
We know that you can't see the final raw SQL before its parsed by the DB, but if you want to simulate the final result, this may help.
<?php
public function showQuery($query, $params)
{
$keys = array();
$values = array();
# build a regular expression for each parameter
foreach ($params as $key=>$value)
{
if (is_string($key))
{
$keys[] = '/:'.$key.'/';
}
else
{
$keys[] = '/[?]/';
}
if(is_numeric($value))
{
$values[] = intval($value);
}
else
{
$values[] = '"'.$value .'"';
}
}
$query = preg_replace($keys, $values, $query, 1, $count);
return $query;
}
?>
hi,
just a qick note to get started without problems when using quotation: PDO does NOT replace given variables if they are wrapped in quotationmarks, e.g.
<?php
$st = $db->prepare( '
INSERT INTO fruits( name, colour )
VALUES( :name, ":colour" )
';
$st->execute( array( ':name' => 'Apple', ':colour' => 'red' ) );
?>
results in in a new fruit like
-> Apple, :colour
without the colour beeing replaced by "red". so leave variables WITHOUT the quotation - PDO will do.
As already pointed out by some folks, DON'T PASS ARRAYS KEYED WITH NAMES TO QUESTION MARK PARAMETERS!
<?php
$sth = $dbh->prepare('INSERT INTO fruit (name, colour, colories) VALUES (?, ?, ?)');
// This is wrong!
// $param = array("name" => "apple", "colour" => "red", "colories" => 150);
// Array must be keyed with integers starting from zero
$param = array("apple", "red", 150);
$sth->execute($param);
I realized that I ran into serious trouble when debugging my PHP scripts from the command line, and despite of going to fetchAll and so, I always got the error
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active.
I realized that I had a double init command:
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8; SET CHARACTER SET utf8;"
The first one is the better choice and removing the latter, the error is gone.
I've used it and it returns booleans=>
$passed = $stmt->execute();
if($passed){
echo "passed";
} else {
echo "failed";
}
If the statement failed it would print failed. You would want to use errorInfo() to get more info, but it does seem to work for me.
The example shows this to generate the needed number of question marks, which is amazingly wasteful:
$place_holders = implode(',', array_fill(0, count($params), '?'));
Instead, just do:
$place_holders = '?'.str_repeat(',?', count($params)-1);
It's been 7 years since simon dot lehmann at gmx dot comment, but today I found myself having problems with a prepared statement involving an INSERT, PDO odbc driver for Microsoft Access and PHP 5.4.7. The prepared statement was done using the prepare + execute method, throwing an ugly
"SQLExecDirect[-3500] at ext\\pdo_odbc\\odbc_driver.c:247" error
and a
42000 ("Syntax error or access violation") SQLSTATE.
He suspects what the problem is and points to a possible solution: using bindParam() or bindValue() and specify a data type.
Well, that seems to be right identifying the source of the problem, but there is a simpler solution that worked for me, simpler and that allows you to continue using pdo::prepare() with ? as parameters and pdo::execute():
the only thing you have to do is, if not done before, a cast of the binded parameters to its specific type (the type that the database is expecting) before putting them in the array you pass to pdo::execute($array).
The following code fails, throwing the error above:
<?php
$name = "John";
$length = "1";
$price = "1.78";
$SQL = "INSERT INTO table (name, length, price) VALUES (?,?,?)";
$arra = array($name, $length, $price);
$sth = $msq->prepare($SQL);
$sth->execute($arra);
?>
This one works for me like a charm:
<?php
$name = "John";
$length = (int)"1"; // the database is expecting this type
$price = (float)"1.78"; // the database is expecting this type
$SQL = "INSERT INTO table (name, length, price) VALUES (?,?,?)";
$arra = array($name, $length, $price);
$sth = $msq->prepare($SQL);
$sth->execute($arra);
?>
I'm using the question-mark way when binding. I tried to use an an associative array when doing
$stmt->execute($values);
having column-names as keys. I thought this would make it easier when rendering the query (as I had variable amounts of parameters).
I found that the execute then could not work with associative array, only with numeric array (with numeric indexes).