Last month, MS announced the preview release of SQL Server ODBC Driver for Linux, a 64-bit binary driver for Red Hat Enterprise Linux 5. This is good news for companies using heterogenous platforms e.g. LAMP stack running a PHP application that connects to both MySQL and MSSQL Server. Meaning, these companies no longer have to use third-party drivers such as FreeTDS that MS doesn't support. Then a few days ago, MS released version 1 of the driver. I immediately downloaded the driver and recompiled PHP with it as a PDO (PHP Data Object) ODBC driver.

His process has five steps to it, including one for making a test script (code included) and another with a few gotchas/performance considerations to keep an eye out for when using the driver.

The first beta release of the SQL Server ODBC Driver for Linux is available for download! As announced in October, the "Multiplatform Team" (a.k.a. the "MPlat Team") has released a preview version of a driver that will provide first-class access to SQL Server from applications running on Linux operating systems. The team is looking for feedback on this release to incorporate into their production-ready release, so try it out and let us know what you think.

He links to a few resources about the release - more details, a link to download the driver and the official documentation.

A Community Technology Preview (a beta release) of v3.0 of the SQL Server Drivers for PHP was released today (see the announcement on the team blog). You can download it here: Download v3.0 of the SQL Server Drivers for PHP. [...] It's important to note that the latter two features are dependent on the next version of SQL Server (code named "Denali"). A preview of Denali can be downloaded for free here (see notes later in this article about the installation process): Download SQL Server Denali CTP 3.

He gives brief summaries (some with example code) of what these three new features have to offer those using SQL Server in their applications. The "buffered queries" allows you to bring your entire result set into memory, making it simpler to interact with as rows/columns. The LocalDB support gives developers a quick way to have a database without the hassle of a server - just connect right to the SQL Server database file. The high availability feature has been included for a while but has a new name in the upcoming release - SQL Server Always On.

I want to make sure that his request gets in front of lots of eyes, so I'm re-posting his request here (below). Jonathan included some links in his post so you can learn more about what the team is considering for the next release of the driver, but he didn't elaborate on "Buffered Queries".

They suggest a few features and ask for choices on which would be the most important to you as a developer - Always On support, SQL Server Serverless Express support, Buffered queries and LOB streaming support in PDO_SQLSRV. To give feedback, send an email to the address mentioned in the post or on twitter/their forums.

Database mirroring is primarily a software solution for increasing database availability. [...] When a PHP application connects to the primary server, the Failover_Partner connection option specifies the name of the server to which the application should connect if the primary server is not available.

[...] These two options, Encrypt and TrustServerCertificate, are often used together. The Encrypt option is used to specify whether or not the connection to the server is encrypted (the default is false). The TrustServerCertificate option is used to indicate whether the certificate on the SQL Server instance should be trusted (the default is false).

In both there's code examples showing the connection strings and what kinds of parameters you can pass to them. He also gives a few examples of scenarios when they might be useful.

This is short post to address a frustration I've seen mentioned on Twitter and in forums a lot: By default, the SQL Server Driver for PHP returns datetime columns as PHP DateTime objects, not strings. This can be especially frustrating if you are not aware of the ReturnDatesAsStrings connection option. By simply setting this option to 1 (or true) when you connect to the server, datetime columns will be returned as strings.

He includes some sample code showing how to use the setting (as a part of the settings array passed in to sqlsrv_connect) and the resulting array key from the fetched results on his sample table. This just gives you one more option for handling dates in your SQL Server-based application, especially if you don't need the full DateTIme object's functionality.

An oversimplified definition of a database cursor might be this: A cursor is database functionality that allows you to point to a certain location within a result set and allows you to move forward (and sometimes backward, depending upon the cursor type) through the result set one row at a time. [...] In the paging [scenario], I'll use a static cursor since that cursor type would seem to satisfy the requirements of many web-based applications.

He shows how to execute a simple query with a dynamic cursor by specifying it in the connection call. He then uses the sqlsrv_num_rows to find the number of records returned and a sqlsrv_fetch_array call to pull just the page you need. He also includes some handy code to paginate the results, complete with links.

A couple of months ago, Rob Allen pointed out in a blog post that no Zend Framework PDO adapter existed for SQL Server. But, he also noted that it would be easy to write one...so he did: https://github.com/akrabat/Akrabat/blob/master/zf1/Akrabat/Db/Adapter/Pdo/Sqlsrv.php. Rob also mentioned that it would be very easy to use his adapter with the Zend Framework, but I wondered just how easy - that's what I'll investigate in this post. (Cut to the chase: it is very easy.)

Brian takes the long way around for those that want the details. He talks about setting up Zend_Tool for Windows, setting up the Zend Framework tutorial and creating the application. This includes setting up the Apache rewrite rules (mod_rewrite), adding in the database information to your application.ini file and creating a basic table on the SQL Server database to connect to (based on SQL included with the tutorial).

The short story is this: If you are using the PDO_SQLSRV driver and you want to execute a query that changes a database setting (e.g. SET NOCOUNT ON), use the PDO::query method with the PDO::SQLSRV_ATTR_DIRECT_QUERY attribute. If you use PDO::query without that attribute, the database setting you expected to change may not be applied to subsequent queries. The longer story has to do with why this is the case, which is what I'll explain in this post.

The problem is that, when changes to settings are made, they don't seem to stick. Future queries act like they were never even updated. The solution to the problem is to use that PDO::SQLSRV_ATTR_DIRECT_QUERY attribute on the connection (set to true). You can see the difference in execution from this to this.

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.