When Carson McDonald tried to get multiple prepared statements to work in his MySQLi code for his application, he got a "commands out of sync" error. Luckily, he's found a solution thanks to the store result.

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.

From Greebo.net there's a recent post that looks at converting the current database functionality in your application over to the MySQLi functionality and making use of prepared statements as a later of protection for your queries.

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.

Johannes Schluter has posted a look at a handy little script that shows an interface between the returned MySQLi results and an SPL iterator.

When using MySQLi's multi_query to send queries which return multiple result sets you have to use a rather unintuitive API which can certainly be improved. Recently I sat down and cooked up a small improvement for that, being an iterator fan I, of course, had to use an iterator for that and implemented the following class.

The class extends the standard Iterator and provides the interfaces to work through the results of the query in your choice of Iterator-supporting looping structure. Example code for the class and its usage are both included.

On the Dev-Explorer blog there's a post made recently about using stored procedures in your MySQL database via the mysqli interface in PHP.

On a new project I am working on I decided to take a look at the MySQLi (MySQL Improved) library. Most of the functions remain the same but it can now be used in object orientated programming which seemed to me as big advantage. Below I look at implementing MySQLi and extending it with your own custom code, along with using it to execute stored procedures.

He shows how to create both pieces of the puzzle - the class extending the mysqli functionality and a simple stored procedure on the database side (to insert users into a table). They're tied together with a PHP class with a "storedProcedure" method that runs a query() with a "CALL" to the procedure name.

From the Procurios blog there's a recent post looking at a method letting you use a foreach on the results from a MySQLi request - SPL Iterators.

Ever wondered why you can't use foreach() on MySQLi Results, and instead have to write less convenient while() loops with fetch_row? Actually, you can use foreach() on MySQLi Results. All it takes is some SPL Iterator magic.

The code examples show how to create an Iterator interface (with rewind, current, key, next and valid methods) to create a ResultIterator class for moving back and forth between the values in the result. This allows you to define the new Iterator object and use the foreach structure like you would a normal result set.

They also show how to bypass this whole problem by using a IteratorAggregate in an extension of the MySQLi interface.

DevShed.com has posted the seventh article in their series looking at the Active Record design pattern in PHP applications. In this latest tutorial they show how to replace the older MySQL client libraries and use the newer mysqli client instead.

Well, as you'll surely recall, I built this class by using the old MySQL library included with the PHP distribution, which is good and efficient. But it's worth making the effort to see how this sample class can be rewritten by using the newer, revamped "mysqli" extension. Thus, this last episode will be dedicated exclusively to doing this, so you can have at your disposal an enhanced versions of the class.

For most of the code, you won't see too much of a change - the methods are named similarly and the results are references differently, but you shouldn't have to make too much of a change.

The Internet Super Hero blog has posted some statistics comparing the connections per second that can be made with the newly introduced persistent connection support coming with PHP 5.3 in the mysqli (ext/mysqli) driver.

Persistent Connections have been a mixed bag. They can give you a significant performance boost by caching (pooling) connections although MySQL is already comparatively fast at establishing connections. However,connections are stored "as-is" in the cache. They are not "cleaned up".

The ext/mysqli driver takes care of this and a few other problems surrounding the persistent connections by cleaning up things like rolling back active transactions, unlocking tables, closing prepared statements and closing handlers. The trick is in a call to the C-API function mysql_change_user() (= COM_CHANGE_USER).

On the TotalPHP site there's a new tutorial showing how to pull data from your database and export it as a CSV file that tools like Excel can read in and use.

There are some occasions where you would want to export your site's information in CSV or similar text format. You might want to do this so you can view reports in a spreadsheet, or you might want an export of your product information to upload to a service like Google Products. Either way the method and end result are essentially the same.

The tutorial shows how to grab the information (via the mysqli functionality in PHP5) and formatting each row with the correct values in a certain order. Finally, the entire contents are echoed back out with the correct header() to force a download on the user's browser.

In a recent post to his blog Rubayeet Islam compared the more traditional way of running a query in MySQL versus a prepared statement with the MySQLi extension.

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.

As Alexey Zakhlestin points out today, Lukas Smith has made the announcement that the MySQL group is finally recognizing the efforts of the PDO developers and supporting them:

Ok, it seems that MySQL AB is finally committing to fix up PDO_MySQL and to generally accept the fact that PDO is the future. Of course mysqli will also be actively maintained. But they will also make mysqlnd play nicely with PDO etc.

There's budgets and time lines for the project so things are already moving along and developers to the project will soon be assigned. Lukas also mentions updated on PHP's side - validating that the documentation for the extensions (mysql and mysqli) are up to date and correct.