Why you Should be using PHP’s PDO for Database Access

Why you Should be using PHP’s PDO for Database Access

Tutorial Details
  • Technology: PHP
  • Difficulty: Moderate
  • Estimated Completion Time: 40 Minutes

Many PHP programmers learned how to access databases by using either the MySQL or MySQLi extensions. As of PHP 5.1, there’s a better way. PHP Data Objects (PDO) provide methods for prepared statements and working with objects that will make you far more productive!

Republished Tutorial

Every few weeks, we revisit some of our reader's favorite posts from throughout the history of the site. This tutorial was first published in May of 2010.


PDO Introduction

“PDO – PHP Data Objects – is a database access layer providing a uniform method of access to multiple databases.”

It doesn’t account for database-specific syntax, but can allow for the process of switching databases and platforms to be fairly painless, simply by switching the connection string in many instances.

PDO - db abstraction layer

This tutorial isn’t meant to be a complete how-to on SQL. It’s written primarily for people currently using the mysql or mysqli extension to help them make the jump to the more portable and powerful PDO.

Database Support

The extension can support any database that a PDO driver has been written for. At the time of this writing, the following database drivers are available:

  • PDO_DBLIB ( FreeTDS / Microsoft SQL Server / Sybase )
  • PDO_FIREBIRD ( Firebird/Interbase 6 )
  • PDO_IBM ( IBM DB2 )
  • PDO_INFORMIX ( IBM Informix Dynamic Server )
  • PDO_MYSQL ( MySQL 3.x/4.x/5.x )
  • PDO_OCI ( Oracle Call Interface )
  • PDO_ODBC ( ODBC v3 (IBM DB2, unixODBC and win32 ODBC) )
  • PDO_PGSQL ( PostgreSQL )
  • PDO_SQLITE ( SQLite 3 and SQLite 2 )
  • PDO_4D ( 4D )

All of these drivers are not necessarily available on your system; here’s a quick way to find out which drivers you have:

print_r(PDO::getAvailableDrivers());

Connecting

Different databases may have slightly different connection methods. Below, the method to connect to some of the most popular databases are shown. You’ll notice that the first three are identical, other then the database type – and then SQLite has its own syntax.

Connection String
try {
  # MS SQL Server and Sybase with PDO_DBLIB
  $DBH = new PDO("mssql:host=$host;dbname=$dbname, $user, $pass");
  $DBH = new PDO("sybase:host=$host;dbname=$dbname, $user, $pass");

  # MySQL with PDO_MYSQL
  $DBH = new PDO("mysql:host=$host;dbname=$dbname", $user, $pass);

  # SQLite Database
  $DBH = new PDO("sqlite:my/database/path/database.db");
}
catch(PDOException $e) {
    echo $e->getMessage();
}

Please take note of the try/catch block – you should always wrap your PDO operations in a try/catch, and use the exception mechanism – more on this shortly. Typically you’re only going to make a single connection – there are several listed to show you the syntax. $DBH stands for ‘database handle’ and will be used throughout this tutorial.

You can close any connection by setting the handle to null.

# close the connection
$DBH = null;

You can get more information on database specific options and/or connection strings for other databases from PHP.net.


Exceptions and PDO

PDO can use exceptions to handle errors, which means anything you do with PDO should be wrapped in a try/catch block. You can force PDO into one of three error modes by setting the error mode attribute on your newly created database handle. Here’s the syntax:

$DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT );
$DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING );
$DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );

No matter what error mode you set, an error connecting will always produce an exception, and creating a connection should always be contained in a try/catch block.

PDO::ERRMODE_SILENT

This is the default error mode. If you leave it in this mode, you’ll have to check for errors in the way you’re probably used to if you used the mysql or mysqli extensions. The other two methods are more ideal for DRY programming.

PDO::ERRMODE_WARNING

This mode will issue a standard PHP warning, and allow the program to continue execution. It’s useful for debugging.

PDO::ERRMODE_EXCEPTION

This is the mode you should want in most situations. It fires an exception, allowing you to handle errors gracefully and hide data that might help someone exploit your system. Here’s an example of taking advantage of exceptions:

# connect to the database
try {
  $DBH = new PDO("mysql:host=$host;dbname=$dbname", $user, $pass);
  $DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );

  # UH-OH! Typed DELECT instead of SELECT!
  $DBH->prepare('DELECT name FROM people');
}
catch(PDOException $e) {
    echo "I'm sorry, Dave. I'm afraid I can't do that.";
    file_put_contents('PDOErrors.txt', $e->getMessage(), FILE_APPEND);
}

There’s an intentional error in the select statement; this will cause an exception. The exception sends the details of the error to a log file, and displays a friendly (or not so friendly) message to the user.


Insert and Update

Inserting new data, or updating existing data is one of the more common database operations. Using PDO, this is normally a two-step process. Everything covered in this section applies equally to both UPDATE and INSERT operations.

2 to 3 step insert and update

Here’s an example of the most basic type of insert:

# STH means "Statement Handle"
$STH = $DBH->prepare("INSERT INTO folks ( first_name ) values ( 'Cathy' )");
$STH->execute();

You could also accomplish the same operation by using the exec() method, with one less call. In most situations, you’re going to use the longer method so you can take advantage of prepared statements. Even if you’re only going to use it once, using prepared statements will help protect you from SQL injection attacks.

Prepared Statements

Using prepared statements will help protect you from SQL injection.

A prepared statement is a precompiled SQL statement that can be executed multiple times by sending just the data to the server. It has the added advantage of automatically making the data used in the placeholders safe from SQL injection attacks.

You use a prepared statement by including placeholders in your SQL. Here’s three examples: one without placeholders, one with unnamed placeholders, and one with named placeholders.

# no placeholders - ripe for SQL Injection!
$STH = $DBH->("INSERT INTO folks (name, addr, city) values ($name, $addr, $city)");

# unnamed placeholders
$STH = $DBH->("INSERT INTO folks (name, addr, city) values (?, ?, ?);

# named placeholders
$STH = $DBH->("INSERT INTO folks (name, addr, city) value (:name, :addr, :city)");

You want to avoid the first method; it’s here for comparison. The choice of using named or unnamed placeholders will affect how you set data for those statements.

Unnamed Placeholders

# assign variables to each place holder, indexed 1-3
$STH->bindParam(1, $name);
$STH->bindParam(2, $addr);
$STH->bindParam(3, $city);

# insert one row
$name = "Daniel"
$addr = "1 Wicked Way";
$city = "Arlington Heights";
$STH->execute();

# insert another row with different values
$name = "Steve"
$addr = "5 Circle Drive";
$city = "Schaumburg";
$STH->execute();

There are two steps here. First, we assign variables to the various placeholders (lines 2-4). Then, we assign values to those placeholders and execute the statement. To send another set of data, just change the values of those variables and execute the statement again.

Does this seem a bit unwieldy for statements with a lot of parameters? It is. However, if your data is stored in an array, there’s an easy shortcut:

# the data we want to insert
$data = array('Cathy', '9 Dark and Twisty Road', 'Cardiff');

$STH = $DBH->("INSERT INTO folks (name, addr, city) values (?, ?, ?);
$STH->execute($data);

That’s easy!

The data in the array applies to the placeholders in order. $data[0] goes into the first placeholder, $data[1] the second, etc. However, if your array indexes are not in order, this won’t work properly, and you’ll need to re-index the array.

Named Placeholders

You could probably guess the syntax, but here’s an example:

# the first argument is the named placeholder name - notice named
# placeholders always start with a colon.
$STH->bindParam(':name', $name);

You can use a shortcut here as well, but it works with associative arrays. Here’s an example:

# the data we want to insert
$data = array( 'name' => 'Cathy', 'addr' => '9 Dark and Twisty', 'city' => 'Cardiff' );

# the shortcut!
$STH = $DBH->("INSERT INTO folks (name, addr, city) value (:name, :addr, :city)");
$STH->execute($data);

The keys of your array do not need to start with a colon, but otherwise need to match the named placeholders. If you have an array of arrays you can iterate over them, and simply call the execute with each array of data.

Another nice feature of named placeholders is the ability to insert objects directly into your database, assuming the properties match the named fields. Here’s an example object, and how you’d perform your insert:

# a simple object
class person {
    public $name;
    public $addr;
    public $city;

    function __construct($n,$a,$c) {
        $this->name = $n;
        $this->addr = $a;
        $this->city = $c;
    }
    # etc ...
}

$cathy = new person('Cathy','9 Dark and Twisty','Cardiff');

# here's the fun part:
$STH = $DBH->("INSERT INTO folks (name, addr, city) value (:name, :addr, :city)");
$STH->execute((array)$cathy);

By casting the object to an array in the execute, the properties are treated as array keys.


Selecting Data

Fetch data into arrays or objects

Data is obtained via the ->fetch(), a method of your statement handle. Before calling fetch, it’s best to tell PDO how you’d like the data to be fetched. You have the following options:

  • PDO::FETCH_ASSOC: returns an array indexed by column name
  • PDO::FETCH_BOTH (default): returns an array indexed by both column name and number
  • PDO::FETCH_BOUND: Assigns the values of your columns to the variables set with the ->bindColumn() method
  • PDO::FETCH_CLASS: Assigns the values of your columns to properties of the named class. It will create the properties if matching properties do not exist
  • PDO::FETCH_INTO: Updates an existing instance of the named class
  • PDO::FETCH_LAZY: Combines PDO::FETCH_BOTH/PDO::FETCH_OBJ, creating the object variable names as they are used
  • PDO::FETCH_NUM: returns an array indexed by column number
  • PDO::FETCH_OBJ: returns an anonymous object with property names that correspond to the column names

In reality, there are three which will cover most situations: FETCH_ASSOC, FETCH_CLASS, and FETCH_OBJ. In order to set the fetch method, the following syntax is used:

$STH->setFetchMode(PDO::FETCH_ASSOC);

You can also set the fetch type directly within the ->fetch() method call.

FETCH_ASSOC

This fetch type creates an associative array, indexed by column name. This should be quite familiar to anyone who has used the mysql/mysqli extensions. Here’s an example of selecting data with this method:

# using the shortcut ->query() method here since there are no variable
# values in the select statement.
$STH = $DBH->query('SELECT name, addr, city from folks');

# setting the fetch mode
$STH->setFetchMode(PDO::FETCH_ASSOC);

while($row = $STH->fetch()) {
    echo $row['name'] . "\n";
    echo $row['addr'] . "\n";
    echo $row['city'] . "\n";
}

The while loop will continue to go through the result set one row at a time until complete.

FETCH_OBJ

This fetch type creates an object of std class for each row of fetched data. Here’s an example:

# creating the statement
$STH = $DBH->query('SELECT name, addr, city from folks');

# setting the fetch mode
$STH->setFetchMode(PDO::FETCH_OBJ);

# showing the results
while($row = $STH->fetch()) {
    echo $row->name . "\n";
    echo $row->addr . "\n";
    echo $row->city . "\n";
}

FETCH_CLASS

The properties of your object are set BEFORE the constructor is called. This is important.

This fetch method allows you to fetch data directly into a class of your choosing. When you use FETCH_CLASS, the properties of your object are set BEFORE the constructor is called. Read that again, it’s important. If properties matching the column names don’t exist, those properties will be created (as public) for you.

This means if your data needs any transformation after it comes out of the database, it can be done automatically by your object as each object is created.

As an example, imagine a situation where the address needs to be partially obscured for each record. We could do this by operating on that property in the constructor. Here’s an example:

class secret_person {
    public $name;
    public $addr;
    public $city;
    public $other_data;

    function __construct($other = '') {
        $this->address = preg_replace('/[a-z]/', 'x', $this->address);
        $this->other_data = $other;
    }
}

As data is fetched into this class, the address has all its lowercase a-z letters replaced by the letter x. Now, using the class and having that data transform occur is completely transparent:

$STH = $DBH->query('SELECT name, addr, city from folks');
$STH->setFetchMode(PDO::FETCH_CLASS, 'secret_person');

while($obj = $STH->fetch()) {
    echo $obj->addr;
}

If the address was ’5 Rosebud,’ you’d see ’5 Rxxxxxx’ as your output. Of course, there may be situations where you want the constructor called before the data is assigned. PDO has you covered for this, too.

$STH->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE, 'secret_person');

Now, when you repeat the previous example with this fetch mode (PDO::FETCH_PROPS_LATE) the address will NOT be obscured, since the constructor was called and the properties were assigned.

Finally, if you really need to, you can pass arguments to the constructor when fetching data into objects with PDO:

$STH->setFetchMode(PDO::FETCH_CLASS, 'secret_person', array('stuff'));

If you need to pass different data to the constructor for each object, you can set the fetch mode inside the fetch method:

$i = 0;
while($rowObj =  $STH->fetch(PDO::FETCH_CLASS, 'secret_person', array($i))) {
    // do stuff
    $i++
}

Some Other Helpful Methods

While this isn’t meant to cover everything in PDO (it’s a huge extension!) there are a few more methods you’ll want to know in order to do basic things with PDO.

$DBH->lastInsertId();

The ->lastInsertId() method is always called on the database handle, not statement handle, and will return the auto incremented id of the last inserted row by that connection.

$DBH->exec('DELETE FROM folks WHERE 1');
$DBH->exec("SET time_zone = '-8:00'");

The ->exec() method is used for operations that can not return data other then the affected rows. The above are two examples of using the exec method.

$safe = $DBH->quote($unsafe);

The ->quote() method quotes strings so they are safe to use in queries. This is your fallback if you’re not using prepared statements.

$rows_affected = $STH->rowCount();

The ->rowCount() method returns an integer indicating the number of rows affected by an operation. In at least one known version of PDO, according to [this bug report](http://bugs.php.net/40822) the method does not work with select statements. If you’re having this problem, and can’t upgrade PHP, you could get the number of rows with the following:

$sql = "SELECT COUNT(*) FROM folks";
if ($STH = $DBH->query($sql)) {
    # check the row count
    if ($STH->fetchColumn() > 0) {

    # issue a real select here, because there's data!
    }
    else {
        echo "No rows matched the query.";
    }
}

Conclusion

I hope this helps some of you migrate away from the mysql and mysqli extensions. What do you think? Are there any of you out there who might make the switch?

Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • Andre

    PDO does not support features like asynchronous queries and seems to be “broken by design”. Oralce MySQL developers recommend to use mysqli connector. See: http://schlueters.de/presentations/20101011_ipc_php_mysql/ipc_mysql_php.pdf

    • Amici

      Regarding that ‘oracle’ document that is mentioning that PDO is broken by design – one of the facts to support that is an example which won’t execute in PDO.
      That example shown is actually broken!
      They try to execute:

      $query = $pdo->prepare(
      “SELECT id FROM table LIMT ?, ?”);
      $query->bindValue(1, $_GET[“offset”]);
      $query->bindValue(2, $_GET[“limit”]);
      $query->execute();

      … and getting an SQL error.

      What’s a “LIMT” keyword here?!? No wonder they got syntax errors.
      I wonder if that was really Oracle that created that doc. If it was – they should be doing some HR-cleaning soon.

      • Eh

        I have no idea where you see a “LIMT” anywhere in that document. The error is PDO putting apostrophe around numbers, for limit and offset, ie. bad.

  • TEHEK

    If write a long-running script (e.g.: cronjob) with PDO, you might see “MySQL server has gone away” error which occurs because MySQL server considers connection to be abandoned and PDO does not reconnect.

    Guys from Digg have written a convenient wrapper:

    http://code.google.com/p/digg/wiki/PDB

    I suggest you use it instead.

  • Madi

    I start using PDO. At first, I don’t understand much about PDO. Thanks Tutsplus

  • Anton P Robul

    Dear author, you have a lot of mistakes in your code, please check and correct,
    example:
    # no placeholders – ripe for SQL Injection!
    $STH = $DBH->(“INSERT INTO folks (name, addr, city) values ($name, $addr, $city)”);

    # unnamed placeholders
    $STH = $DBH->(“INSERT INTO folks (name, addr, city) values (?, ?, ?);

    # named placeholders
    $STH = $DBH->(“INSERT INTO folks (name, addr, city) value (:name, :addr, :city)”);

    you forgot ->prepare before all (“INSERT

    in this: values (?, ?, ?);
    you forgot quote

    your mistakes are reproduce by other author’s blogs

    • iben

      Anton P Robul: You’re right! These mistakes are real annoying. Since I started to learn using PDO from this article, it took me a whole lot of time until I figured out that those “prepare”s are missing making my code unusable.

      AUTHORS PLEASE CORRECT!

    • nik

      I also spent a bit of time scratching my head over this, as I am also learning PDO from this article, and the mistakes confused me. This article has been published for quite some time, I would hope that nettuts checks comments every once in a while. Otherwise, its a very helpful tutorial.

    • Kyle

      Hmmm I think it’s silly to be using his code verbatim. Great for learning but if you’re returning an SQL error then check SQL syntax.

      These things are semantics. If you’re developing ANYTHING you should be able to correct these without trouble. I reckon those having issues have learnt a valuable lesson

      I feel maybe some words used are abrasive and unnecessary. Thanks Eric, for a great article. Tiny SQL strings aside, great explanation of the PDO object.

      Can you believe I just stumbled upon it recently. shock|horror|gasp. I’m glad this was republished!
      K

      • http://www.facebook.com/people/Ball-Guy/100000230312229 Ball Guy

        Any time you write an article, you should be painstakingly check for errors. When he/she publishes an article, a writer is establishing him/herself as an authority on the subject. Readers have a reasonable right to expect the code to be correct and it’s ok if they express that. As I write my own, I make sure it is correct to the best of my ability but gladly accept any criticism (even if it does have the occasional “you suck” in it) and correct it if it warrants that.

  • http://zagalski.pl zagal

    I’ve been using PDO since I started writing PHP apps. Anyway, it’s nice article.

    Best regards,
    zagal

  • Esen

    CUBRID Database (http://www.cubrid.org) also officially provides PDO Driver through PECL (pdo_cubrid). You may want to update the article.

  • http://indiatour24.com/ تور هند

    this very nice
    tankyou. tutsplus.com
    i Love tutsplus.com

  • Matthew

    Yeah great article, thanks guys.

    *But could somebody please put those ‘prepares’ in.

  • Rash

    As much as I like this web site and all its sister or parents pages, I can’t but help the codes are filled with errors. Maybe double-checking and trying to make them run before you post them would help.

  • Mike

    The PDO library seems to do exactly the same as the mysqli object. So what’s the point?

    PDO isn’t a database abstraction (according to php.net). This is because specific database calls are used in the arguments to the functions, so if the database changes then ALL the calls to the functions change too thus not making it an abstraction layer. Also it isn’t really a data abstraction layer either.

    According to php.net it IS a data-access abstraction layer, but to me if it uses mysql statements as arguments to functions, then it isn’t even abstracted in that way.

    In short it seems pointless. I am obviously wrong so please can someone explain to me it’s benefits?

    Thanks!

    • Sean

      Mike, it’s not about building an abstraction between PDO and your database, it’s more about building a facade/strategy pattern which makes switching between databases faster and easier (as you then only need to change the connection method).

      Thus, any abstraction you build on top of PDO isn’t going to require that you’re writing database-specific code.

      You could write a “Database” class, where you’re using PDO under the hood, and supplying whatever interface you’d like to your other classes.

      From there, aside from the initial connection, your Database class is going to work in any program, on any database (assuming that you are using a supported database, and you’re not trying to write proprietary SQL statements which are unsupported in other databases).

      Ultimately, instead of writing a database class which selectively loads modules based on whether it’s connecting to a MySQL or a PosgreSQL database, you can just write your interface and PDO will do the rest, and then your class stays nice and portable.

      • cHao

        Assuming *your SQL* is nice and portable. Which, if you’re doing more complicated stuff, it won’t be.

        The fact that you don’t have to switch all your mysql_querys to pg_query or whatever, doesn’t mean much if the SQL isn’t compatible. And most of us end up using our database’s “extensions” to SQL, often without realizing it.

  • http://codebycoady.com Alex Coady

    Thanks for the tutorial – I’m a decent PHP developer but have yet to switch to PDO from the standard mysql_* functions. I’m starting today, though!

    1 question:

    For the FETCH_CLASS example, you use the propery $addr, but in the constructor you use address. Is this a typo? Surely that wouldn’t actually change anything as it is..

  • Hector

    from which version of php was this released to

    • Ollie

      Works on 5.1+

  • phpcoder

    Good tutorial, but there are so many MISTAKES in the code snippets.
    That’s very annoying.

  • http://parsigate.com parsigate

    I’ve been using PDO since I started writing PHP apps and love it.

  • http://blog.webtech11.com/ Jogesh sharma

    Thanks a lot for the explanation about the PDO, i just thinking to use PDO but don’t know how to use it.

    Your post is really help me a lot to learn.

  • crud

    I never wrote to MySQL. I got so bungled in data-sanitizing and magic quotes nonsense and injection security that my db block remained incomplete. Thank god i can move forward now with PDO and tweak my classes to use PDO’s OOP goods. This article gives me the toolbox. People who niggle about typos… who doesn’t check the definitive guides before implementing? This is a rockin survey article.

  • http://no saju

    i like http://net.tutsplus.com
    because it is so helpful for developers.

  • Alex

    This Tut is titled Why you Should be using PHP’s PDO for Database Access.

    I do not see anything in this tut that answers this question. It merely goes on about how to do it.

    You are suggesting moving away from mySQLi, to PDO, when in fact Oracle, the Current owners of My SQL,

    Excplicitly reccommend mySQLi,

  • David Orr

    Don’t automatically use PDO::prepare() for all of your queries. There is a performance penalty to using prepared statements because an additional roundtrip (request and response) has to be made to the database server. Using PDO::query() is about 2-3x faster if you are only submitting a single query (there are a few performance tests online that show this).

    The only speed advantage with using prepare() is if you are preparing a statement one time but submitting it with different data thousands of times in the same script.

    PDO::prepare() does have the advantage of escaping your data for you, so you have to be sure to use PDO::quote() when using PDO::query() with untrusted data (just use it with all data variables when you include them in a query to be safe).

    • Erik
      Author

      David: this isn’t entirely correct. Unless you explicitly tell it otherwise, PDO actually emulates real prepared statements; there is no second trip to the server.

  • Thorsten

    Using PDO is a mess. Start writing PDO ODBC driver on Doctrine2 for Exasol.
    But PDO ODBC do not support bindParam od bindValue. It do not support any kind of binding. You always get en empty result set.

    Trying to set PDO::setAttribute PDO::ATTR_EMULATE_PREPARES = true, for emulating the binding by PDO also dont’ work. While trying to get the current state of ATTR_EMULATE_PREPARES [getAttribute( PDO::ATTR_EMULATE_PREPARES) ] results in an error: The driver is not supporting it.

    Sorry but in this state of PDO, where I must repair the driver (PDO ODBC), PDO is not realy for a production environment.

  • Andrey

    Will someone please explain me the following point:
    if as stated “… the ->lastInsertId() method is always called on the database handle” then how to indicate which particular table we are interested to analyze in terms of the last used record number?
    Thanks a lot.

  • Mahdi

    I was googling a question about PDO when I came to this page and although it is a great tutorial but still could not find the answer. Could you please help me out in this:

    After using a SELECT with MySQL we have a function mysql_num_rows() which we can use to check if any data is returned or not or how many data has been returned.
    However it seems we do not have the same option with PDO and we need to either make another query to count it or have to fetch data and count how many we fetched.
    Problem arises when I need to read data inside a method in a class and return result set. So I don’t want to fetch data but want to return something else if no result set was returned. I also don’t like the idea of another query to read how many data was returned.
    Is there a simple way just to check and see if PDO query request has returned a result set or not.
    Kind Regards,
    Thanks a lot

    • Fredrik

      How about this? $PDOStatement->rowCount();

      • Mahdi

        Will try it.

        Thanks a lot.

  • John

    Excellent guide on the PDO. I’ve started using the PDO myself and really like it! One thing that may be useful is doing encryption/decryption of data in mySQL. While that is not a “PDO” specific function, I found a resource that shows how to do encryption/decryption with PDO at http://www.virtualsecrets.com/pdo-encryption-mysql-from-php.html

  • Really?

    If a tutorial has as many mistakes as this one does and it doesn’t even address the question its title poses, is it really a good tutorial? Seriously — think about that for a second.

    envato is starting to feel more and more like a network for chumps. Disappointing.

  • Cordell

    Could someone, anyone, please explain the difference between e.g. “PDO sqlsrv” and just “sqlsrv.” The reason I’m at this article is because I’m obviously searching for some clarity that no one else seems to find relevant. I’m being asked by an application install which driver I want to implement, and apparently it could be either.

    It sounds like the issue is a programming preference. Even at Microsoft, they come combine the two topics (sqlsrv and PDO sqlsrv) but no one’s being specific about which applications they apply to. I can’t tell if one supports the other or in what order they interact (do they?).

    Basically I’m installing a product that I intend to use, not write. Why choose one over the other…

    I may sound perturbed, but I read stuff all day–no answer. Do applications respond to either? That’s my first question. Is there a way to know which is better, or is there an exclusion somewhere?

    Well that’s enough. Any clear answer will suffice. Thank you for sparing the time in advance!

  • Tom

    Found the article rather misleading. When I think about PDO I am usually thinking about parameter binding. Best I can tell this still DOES NOT binding parameters.

    Think this describes one of the things I ran into.

    https://connect.microsoft.com/SQLServer/feedback/details/527188/paramater-datatype-lookup-returns-incorrectly

    In short this is still not a viable alternative to DBLIB and freeTDS.

    • Tom

      Whoops, that reply was actually for another article.

      • Mike

        Shows… ;)

  • TravisO

    This tutorial is laden with code breaking typos!

    There are a whole bunch of places where the author meant
    $DBH->prepare(”
    but typed
    $DBH->(“

  • Max

    There is no need to error handle everything you do in PDO thats a newb statement.

    • http://comradedeveloper.blogspot.com/ Comrade

      There is a need to handle any error in your application if you really want create a stable one.

  • http://atailoredweb.com Wrwipeout

    All of the insert functions are missing “prepare”. Anyone who is learning for the first time will be uberly confused. For those people, see below:

    $STH = $DBH->(“INSERT INTO folks (name, addr, city) value (:name, :addr, :city)”);

    should be:

    $STH = $DBH->prepare(“INSERT INTO folks (name, addr, city) value (:name, :addr, :city)”);

    • test

      Good call, this helped.

    • Ranjan

      @Wrwipeout: As you got it, then that means tutorial served the purpose

      • Mylo

        No, actually I was pretty confused. I’m trying to learn PDO as I’m pretty used to older methods of creating database connections. PDO is confusing enough as is without the added missing code, so I’m glad somebody could clarify…

    • http://www.code-nevis.ir Nima

      hey this is a test, pls delete this cm!

  • Ranjan

    Thanks for the great tutorial and from now on switching to PDO.

  • EmRa

    Thanks For This Great Tutorial!

  • Sim$o

    ty!!!!! rlly helpful

  • lukas

    In Prepared Statements section the examples should probably say
    $STH = $DBH->prepare(…
    instead of $STH = $DBH->(….

  • Rick

    Hey, thanks it was very helpful as i’m switching from deprecated mysql_* to PDO.

  • http://www.facebook.com/profile.php?id=100000927714798 Simerdeep Singh

    excellent ..this is what I have been searching for days. Makes my life easy now..

  • CuriousCursor

    Perhaps the most well-rounded article I’ve read in all my years of following the tuts sites (and I’ve been following ever since there was only psdtuts!)

  • wArLeY996
  • innocentumesh

    Really Helpful…………. Thanks!!!! :>)

  • Jay

    getMessage();
    }

    # close the connection
    $DBH = null;

    ?>

    When running the php file in my server, i get the following error:

    Parse error: parse error, unexpected ‘{‘ in
    /home/web/i/htdocs/search/pdo.php on line
    8

    Any idea?

    • josh

      No need for the } after getMessage; unless it’s ending a try{}catch{}

  • Viagravated

    Thanks Wipeout, stuck for a bit on this one until I scrolled down here to the comments. Maybe in the next year or two the author will come back and fix the tutorial.

  • http://www.facebook.com/pmugal symftech

    PDO_DBLIB is no longer supported on windows for php 5.3 and higher, instead sqlsrv from microsoft should be used.

  • Favourites Multimedia

    Fantastic post, covered everything except how to install or “general overview” of how to atleast. thanks though

  • Brian

    The fact that no one has bothered to go through and correct this code reflects pretty poorly on the site. Normally you guys are better than this.

  • Suyog Sawant

    whatever shared on this blog is GOOD and in neat and clean fashion

    But more thing have to be exposed, for an beginner this is not all

    statements: Prepare, Delete, and many more………………

    You must do, to make this blog much more effective

  • Mas Cabeza

    This is really an excellent tutorial. Thanks

  • Lil Josh

    Under the Prepared Statements section in the code sample (line 5), you’re missing a double quote. Not sure if anyone has pointed this out yet. Also I threw up some PDO code samples (SELECT, INSERT UPDATE) if anyone wants a quick reference cheat sheet: http://liljosh.com/pdo

  • Blowme

    This is the worst article I have ever read. The amount of mistakes is absurd.
    I’m in awe that people would say that this tutorial is in any way better than garbage!