The fourth video in the Programming With Anthony series is live! In this video, we'll explore the basic principles of prepared statements, and why you should use them instead of using escaped input directly in queries.

You can watch this latest video over on YouTube. You can also check out the previous videos in the series while you're there covering paradigms, encryption and references.

Even so not every PHP Developers knows WHY we don't use references pretty much every core function and every somewhat modern framework avoids them so people adapted this best practice. The leftovers in the PHP core, like sort() or str_replace(), are exceptions to the rule. So if the common consensus is, or at least 'should be', that we should not use references then maybe we should start looking for places where they hurt and how we could fix them?

He talks about prepared statements and one thing he sees that makes it a "hard sell" to developers needing a good way to query their databases. He points out the difference in code required between the normal MySQL calls and mysqli (hint: it's more) and shows how to use an abstraction layer to make things a bit easier. He points out the downfalls of using this approach, mainly the performance hit you get (from using his fetchAll method).

Now prepared statements were a nice invention some 30 years ago abut they weren't meant for making things secure and so they do have some shortcomings: One issue is that preparing and executing a query adds a round-trip to the server where it then requires resources. [...] With prepared statements you first have to build the list of place holders (the exact amount of place holders (?) separated by a comma, without trailing comma) and then bind the values and mind the offsets when having other values - this typically becomes ugly code.

He includes the code for his alternative, a function using the mysqli extension to let you create dynamic SQL that still uses placeholders and proper escaping to prevent both SQL injection issues and resources problems caused by the multiple hops back to the database.

There are a couple issues that appear to make these methods less flexible than we'd hope. For one, we must utilize the bind_result method, and pass in a specific number of variables. However, what happens when this code is within a class, and we won't immediately know how many variables to pass? Luckily, there's a solution! I'll show you what it is in today's video tutorial.

The tutorial is screencast but they've also included the full code ready for cut and pasting into your favorite editor of choice.

Details about this error can be found in the mysql docs. Reading those details makes it clear that the result sets of a prepared statement execution need to be fetched completely before executing another prepared statement on the same connection.

He gives code snippets that are "before" and "after" examples of what he had to change to get things working. Each time its executed, the "store_result" call is made and the result set is pulled out of the prepared statement.

Okay, you've got like a zillion SQL queries in your PHP app, and probably 95% of them have a WHERE clause, and you need to make them safe so people will still download and use your app. Because if you don't fix your injection issues, I will rain fire on your ass. These are the steps you need to take to convert to prepared statements.

The guide is two steps you'll need to make the transition - "PHP 4 is dead. Upgrade to PHP 5" and "make sure your hoster has MySQLi". The major part of the update is under the first point where he gives code examples and suggestions to follow about how to "harden" your environment to prevent and issues that lax SQL methods might have caused and a simple example of a move from MySQL to MySQLi.

Consider a PHP-MySQL application where the information of 1000 users is being retrieved from the database by running a for loop [...] in each iteration, the first thing the MySQL engine does is to parse the query for syntax check. Then it sets up the query and runs it. Since the query remains unchanged during each iteration(except for the value of user_id), parsing the the query each time is definitely an overhead. In such cases use of prepared statements is most convenient.

He explains what prepared statements are and some of the advantages around them and includes some benchmarking examples to show the differences - about a five second jump in favor of MySQLi.

PDO_MYSQLND is in the PHP CVS repository at php.net: PDO_MYSQL has been patched (PHP 5.3, PHP 6.0). Try out PDO_MYSQL with the MySQL native driver for PHP (mysqlnd). Its has new features.

They do a short recap of what the native driver libraries are all about and some of the advantages to using them. They look at some of the "memory tricks" supported by the driver and a look at the prepared statement and procedure support.

There still seems to be a lot of confusion over the differences between the two extensions despite the length of time that mysqli has been in the wild. I wanted to briefly review the four major benefits of mysqli.

Here's the list

• Prepared Statements
• Secure MySQL connections
• Multi query
• Object Oriented Interface

He also includes a few more links to further information (besides the explanation for each of the topics listed above) including an article from the Zend Developer Zone and a tutorial covering making the switch to MySQLi.

In this last tutorial in the series I'm going to show you how to run prepared queries, but in this case we're going to include named parameters into them. Additionally, I'm going to take a quick look at some additional methods bundled with this extension. These new methods can be really useful for working with transactions, in case you want to use this feature with the database system of your choice.

They start with a simple approach to using prepared queries before moving on to an alternate method - binding parameters to the query via bindParam. They wrap up the article with a look at using transactions, both commits and rollbacks.