If some of you have been using PHP on Windows with SQL Server 2005, you may have hit some problems especially if you wanted to exploit new features of SQL Server 2005 like xml datatype, NVARCHAR(MAX), etc.

The driver that had the better support for these were the PHP ODBC wrapper combined with the SQL Server 2000 ODBC driver.  The bad news is, by default, PHP ODBC uses server-side dynamic cursors which is the thing Microsoft says to avoid as much as possible (unless you have a need for that).  It is very slow, server resource intensive, poor performing, etc.

Some succeeded to change the way ODBC were handling resultset by using a hint at connection time (SQL_CUR_USE_ODBC), but it didn’t help for us.  Some perfectly valid parameterized queries where just giving unexpected results.

I even downloaded PHP’s source code to see why it was using dynamic cursors by default.  If I could, at least, change the default cursor, we may had a little performance increase…  It was hardcoded to “dynamic” with the following comment on top of it:

Try to set CURSOR_TYPE to dynamic. Driver will replace this with other type if not possible.

So next thing would be to change it and recompile…  forgot about it!

Then, some time at the end of 2007, I discovered an alpha community preview release of a new driver made by Microsoft.  Wohoo!  This version was unstable with xml datatypes at a point that it was making my Apache server crash… 

Fortunately, the official release finally got out et we are testing it for some time now!  So far, there are no blocking bugs.  The quality is good enough that I took the time to created a Creole wrapper (our web application uses Creole as database wrapper API) for it and start using it full-time on our develpment environment.

Here are some observations:

• On my laptop, based on a non-official, non-extensive performance test, I had a 400% to 500% performance boost for fetching 200 records of a large (numerous fields) table.
• UTF-8 support exists, but conversion must be done manually, field by field (better have a database wrapper API…) and at a huge performance cost.
• UTF-8 support works only for query parameters and resultset values.  If you hardcoded a query filter (I know it is not a best practice, but we all supports legacy applications…) you will have to rewrite it with parameters or drop UTF-8 support.
• If you are using PHP from a Linux server, you are still left alone because the Microsoft driver relies on the ODBC SQL Server Native Client driver that works only on Windows.

If you need more information about the driver, you can visit the Microsoft blog and forum.