I wanted to extend PDO class to store statistics of DB usage, and I faced some problems. I wanted to count number of created statements and number of their executings. So PDOStatement should have link to PDO that created it and stores the statistical info. The problem was that I didn't knew how PDO creates PDOStatement (constructor parameters and so on), so I have created these two classes:

Classes have properties with original PDO and PDOStatement objects, which are providing the functionality to PDOp and PDOpStatement.From outside, PDOp and PDOpStatement look like PDO and PDOStatement, but also are providing wanted info.

If you use $dbh = new PDO('pgsql:host=localhost;dbname=test_basic01', $user, $pass); and you get the following error:PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[08006] [7] could not connect to server: Connection refused\n\tIs the server running on host "localhost" and accepting\n\tTCP/IP connections on port 5432?'then as pointed out under pg_connect at: http://www.php.net/manual/en/function.pg-connect.php#38291******you should try to leave the host= and port= parts out of the connection string. This sounds strange, but this is an "option" of Postgre. If you have not activated the TCP/IP port in postgresql.conf then postgresql doesn't accept any incoming requests from an TCP/IP port. If you use host= in your connection string you are going to connect to Postgre via TCP/IP, so that's not going to work. If you leave the host= part out of your connection string you connect to Postgre via the Unix domain sockets, which is faster and more secure, but you can't connect with the database via any other PC as the localhost.******Sincerely,Aouie

I use PDO with the ODBC driver to query stored procedures in a MS SQL Server 2005 Database under Windows XP Professional with IIS 5 and PHP 5.1.4. You may have the same problems with a different configuration.

I experienced 2 very time consuming errors:

1. The first one is when you return the result of a SELECT query, and you get the following clueless message:>>> Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[24000]: Invalid cursor state: 0 [Microsoft][SQL Native Client]Invalid cursor state (SQLFetchScroll[0] at ext\pdo_odbc\odbc_stmt.c:372)' in (YOUR_TRACE_HERE) <<<Your exact message may be different, the part to pay attention to is "Invalid cursor state".

-> I found that I had this error because I didn't include "SET NOCOUNT ON" in the *body* of the stored procedure. By default the server returns a special piece of information along with the results, indicating how many rows were affected by the stored procedure, and that's not handled by PDO.

2. The second error I had was:>>> Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[22003]: Numeric value out of range: 0 [Microsoft][SQL Native Client]Numeric value out of range (SQLFetchScroll[0] at ext\pdo_odbc\odbc_stmt.c:372)' in (YOUR_TRACE_HERE) <<<Another meaningless error "Numeric value out of range"...

-> I was actually returning a date datatype (datetime or smalldatetime) "as is", that is, without converting it to varchar before including it in the result set... I don't know if PDO is responsible for converting it to a PHP datatype, but it doesn't. Convert it before it reaches PHP.

If you intend on extending PDOStatement and your using setAttribute(PDO::ATTR_STATEMENT_CLASS, ...)you must override the __construct() of your PDOStatement class.failure to do so will result in an error on any PDO::query() call.Warning: PDO::query() [function.PDO-query]: SQLSTATE[HY000]: General error: user-supplied statement does not accept constructor arguments

$t1 = isset($_GET["t1"])?$_GET["t1"]:1; // need to be securised for injonction$t2 = isset($_GET["t2"])?$_GET["t2"]:2; // need to be securised for injonction$t3 = isset($_GET["t3"])?$_GET["t3"]:3; // need to be securised for injonction

$ret = $db->query("SELECT * FROM table_test WHERE t1=? AND t2=? AND t3=?",$t1,$t2,$t3);//$ret = $db->insecureQuery("SELECT * FROM table_test WHERE t1=".$db->quote($t1));

When using persistent connections, pay attention not to leave the database connection in some kind of locked state. This can happen when you start a transaction by hand (i.e. not through the PDO->beginTransaction() method), possibly even acquire some locks (e.g. with "SELECT ... FOR UPDATE", "LOCK TABLES ..." or in SQLite with "BEGIN EXCLUSIVE TRANSACTION") and then your PHP script ends with a fatal error, unhandled exception or under other circumstances that lead to an unclean exit.

To use that database again, it may then be necessary to disable the persistence attribute to get a new database connection or restart the web server. (Persistent connections should not work with a PHP-CGI anyway.) It does not work (tested with PHP 5.2.3/WinXP and SQLite) to close a persistent database connection - it will not actually be closed but instead returned to PDO's connection pool.

The only thing you can do to resolve the lock as a regular user (I imagine) is to try and get all of your persistent connections in a single script and unlock the tables resp. end the transactions with the appropriate SQL statements ("UNLOCK TABLES" in MySQL, "ROLLBACK" for transactions). Should they fail, there is no problem, but one or some of them might succeed and thereby resolve your locking problem.

Be careful with PDO extends : if you use the smileaf's example, PDO will close the connection only at the end of the script, because of the "array( $this )" parameter used with the setAttribute() method.

Instead, I use only this : $this->setAttribute( PDO::ATTR_STATEMENT_CLASS, array( $this->statementClassName, array() ) );

And in prepare() and query() method you can populate the "dbh" if you really need it.

Not all PDO drivers return a LOB as a file stream; mysql 5 is one example. Therefore when streaming a mime typed object from the database you cannot use fpassthru.

The following is a modified example that works with a mysql database. (Tested FreeBSD v 6.2 with mysql 5.0.45 and php 5.2.3)

<?phpob_start();$db = new PDO('mysql:host=localhost;dbname=<SOMEDB>', '<USERNAME>', 'PASSWORD');$stmt = $db->prepare("select contenttype, imagedata from images where id=?");$stmt->execute(array($_GET['id']));$stmt->bindColumn(1, $type, PDO::PARAM_STR, 256);$stmt->bindColumn(2, $lob, PDO::PARAM_LOB);$stmt->fetch(PDO::FETCH_BOUND);ob_clean();header("Content-Type: $type");echo $lob; // fpassthru reports an error that $lob is not a stream so echo is used in place.ob_end_flush();?>

Please note the inclusion of buffer control. I only needed this when using 'include','include_once','require', or 'require_once' - my feeling is there is a subtle issue with those options as even an empty include file caused a buffer issue for me. === AND YES, I DID CHECK MY INCLUDE FILES DID NOT HAVE SPURIOUS WHITESPACE ETC OUTSIDE THE <?php ?> DELIMITERS! ===

1. If PDO is built as a shared modules, all PDO drivers must also bebuilt as shared modules.2. If ext/pdo_sqlite is built as a shared module, ext/sqlite must alsobe built as a shared module.3. In the extensions entries, if ext/pdo_sqlite is built as a sharedmodule, php.ini must specify pdo_sqlite first, followed by sqlite.

because of ZDE 5.0 and other PHP-IDEs do not seem to support PDO from PHP5.1 in code-completion-database yet, I wrote a code-completion alias for the PDO class.NOTE: This Class has no functionality and should be only included to your IDE-Project but NOT(!) to your application.

<?php/** * This is a Code-Completion only file * (For use with ZDE or other IDEs) * * Do NOT include() or require() this to your code * * @author Matthias Leuffen */

If you plan on using prepared statements to issue a series of KILLs, think again. PDO apparently does not support this, and will tell you, assuming you don't put any parameters in the statement (a situation in which it would be pointless to use prepared statements anyway). If you do specify some ?-mark parameters, it will just spit out an error that doesn't help at all.

I have seen a lot of user struggling with calling mysql procedures with in/out/inout parameters using bindParam. There seems to be a bug or missing feature within the mysql C api. This at least I could find out after reading a lot of posts at different places...

It appears that PDO SQL statements can not make use of /* */ comments. Or at least, when I was trying to use them with mine it was crashing without error and giving me a blank page (even though I surrounded with try catch block).

I ran into a real annoying bug/feature when using PDO for SQL statements that use SQL user variables. I was working on some logic for a Geo Proximity Search for an events-venues system (sharing is caring so it's below) and it just wouldn't take and the errors returned were garbage. The SQL was sound as I verified it. So if you're having this issue, I hope this helps. What you need to do is break apart the query into two...

There is a book titled "Learning PHP Data Objects" written by Dennis Popel and published by Packt. There is a post with further links (ordering, reviews) at author's blog: http://www.onphp5.com/article/58