Brian Swaan has a new post to his blog talking about why you, in your SQL Server-based application, pass the parameters in by reference.

Last week at JumpIn Camp we spent quite a bit of time focusing on the SQL Server Driver for PHP. As developers worked to build SQL Server support into their applications, they had lots of questions about how both the SQLSRV and PDO_SQLSRV drivers work under the hood. One of the questions that came up was "When using the SQLSRV driver to execute parameterized queries, why do I have to pass parameters by reference?"

He includes a simple code example to show this passing by reference - first without it on the call to sqlsrv_prepare (and the warning message it gives) then the more correct version of passing in the past parameter by reference.

The SQL Server Driver for PHP team understands that passing parameters by reference is not ideal. [...] With that said, the team is continuing to investigate solutions that would produce expected behavior without passing parameters by reference.

In this latest post to his blog Rob Allen takes a look at a problem he had when installing a project that used SQL Server as its data source - it just didn't work.

A good proportion of the projects my company undertakes end up on Windows servers with IIS and SQL Server and hence we use the SqlSrv PHP extension from Microsoft. We don't host any of these projects ourselves and leave it up to the client's IT department. This is the main reason that we use a database abstraction layer, Zend_Db, in our case as we can swap the underlying database out with less hassle. A couple of weeks ago, I came across a problem when installing our app onto the client's server. It didn't work. This was a surprise as we have a few Windows Server VMWare installations on which we had tested and they had worked fine.

He ultimately boiled it down to an exception from the SQL Server - "String data, right truncation". As it turns out, with the version 2 of the sqlsrv driver, you can't have a field name longer than 30 characters. There's two obvious workarounds - shorten the field name or use a PDO interface. Since one doesn't exist (well, not formally) he created his own you can drop into your application if you have the need.

Brian Swan has posted the second part of his series looking at the difference between the MSSQL driver and the SQLSRV drivers for connecting to SQL Server databases from PHP (part one can be found here). He gets a bit more detailed in this second post.

I’m aiming to provide a high-level comparison that you might use if you were considering moving to the SQLSRV extension, but I think there is also some interesting information if you are just curious about the differences. [...] In cases where a short note wasn’t enough (and there were several of these), I’ve provided relevant links to topics in the SQLSRV documentation.

He talks about things that one offers that the other doesn't, like prepared statements (sqlsrv) and working with stored procedures (mssql). He also mentions error handlng, persistent connections and scrollable cursors in sqlsrv. Finally he gets into a one-to-one function comparison of the two drivers with the sqlsrv function list coming up a bit short compared to the features of the more recend (and well-supported) mssql driver.

In a new post to his blog Brian Swan compares the database drivers for MSSQL and SQLSRV by what they have to offer and what the real differences are to your applications.

In this post I want to begin looking at some of the differences between the two drivers and perhaps gain an understanding of why the mssql driver continues to be used (although I have some good guesses). There are lots of comparison points between the mssql and sqlsrv drivers. I’ll break my comparison into two posts, focusing on high-level differences in this post and then dive into an API comparison in the next post.

This first of the two parts looks at some of the differences between the two - the Microsoft support for the sqlsrv driver vs community-driven mssql and the fact that they're very different "under the hood" (see this diagram).

Rob Allen has posted the settings you'll need to connect the Zend Framework with a SQL Server backend (via SqlSrv).

It turns out that fellow challenger Juozas Kaziukenas also needs a connection between Zend Framework and SQL Server, so we have joined forces to create App_Db_Adapter_SqlSrv and associated classes. Juozas started a project on codeplex at http://zfmssql.codeplex.com/ and has enabled me to commit to the project too.

Rob based his implementation on this and has set up his application.ini file to use the SQLSRV adapter (example included).