PDO::exec

PDO::exec —
Execute an SQL statement and return the number of affected rows

Description

publicintPDO::exec
( string$statement
)

PDO::exec() executes an SQL statement in
a single function call, returning the number of rows affected by the
statement.

PDO::exec() does not return results from a SELECT
statement. For a SELECT statement that you only need to issue once
during your program, consider issuing PDO::query().
For a statement that you need to issue multiple times, prepare
a PDOStatement object with PDO::prepare() and issue
the statement with PDOStatement::execute().

Parameters

Return Values

PDO::exec() returns the number of rows that were modified
or deleted by the SQL statement you issued. If no rows were affected,
PDO::exec() returns 0.

Warning

This function may
return Boolean FALSE, but may also return a non-Boolean value which
evaluates to FALSE. Please read the section on Booleans for more
information. Use the ===
operator for testing the return value of this
function.

The following example incorrectly relies on the return value of
PDO::exec(), wherein a statement that affected 0 rows
results in a call to die():

User Contributed Notes 8 notes

It's worth noting here, that - in addition to the hints given in docs up there - using prepare, bind and execute provides more benefits than multiply querying a statement: performance and security!

If you insert some binary data (e.g. image file) into database using INSERT INTO ... then it may boost performance of parsing your statement since it is kept small (a few bytes, only, while the image may be several MiBytes) and there is no need to escape/quote the file's binary data to become a proper string value.

And, finally and for example, if you want to get a more secure PHP application which isn't affectable by SQL injection attacks you _have to_ consider using prepare/execute on every statement containing data (like INSERTs or SELECTs with WHERE-clauses). Separating the statement code from related data using prepare, bind and execute is best method - fast and secure! You don't even need to escape/quote/format-check any data.

PDO::eval() might return `false` for some statements (e.g. CREATE TABLE) even if the operation completed successfully, when using PDO_DBLIB and FreeTDS. So it is not a reliable way of testing the op status.

PDO::errorInfo() can be used to test the SQLSTATE error code for '00000' (success) and '01000' (success with warning).

Remember though, if you are doing a lot of inserts, you'll want to do it the manual way, as the prepare statement will speed up when doing multiple executes(inserts). I use this so I can place all my SQL statements in one place, and have auto safe quoting against sql-injections.

If you are wondering about the fetch after, remember some databases can return data SELECT-like data from REMOVE/INSERTS. In the case of PostgreSQL, you can have it return you all records that were actually removed, or have the insert return the records after the insert/post field functions, and io trigger fire, to give you normalized data.

"PDO::prepare(): 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."

So, instead of fetch(), use fetchAll(), it will make you less insane.

Incidentally, the INSERT statement that I was issuing, if the record that I needed to update didn't yet exist, after the initial fetch() command worked perfectly.