An update on our CTP2 release

It's been about two weeks since we released our CTP2 for the SQLSRV and PDO_SQLSRV drivers. While we've been actively monitoring and responding to feedback on our blog/forums, we have also been busy with the last set of "mini features" to complete our CTP2 release.

The “mini features” are limited to our installer for our Web Platform Installer (WPI) release. While our MSDN Download Center release is based on simpler IExpress technology (simple file uncompress and copy), the WPI installer is based on the Windows Installer technology – a requirement for WPI. Since WPI installs the VC6 Non-Thread Safe (NTS) version of PHP 5.2.13, our WPI release installer only installs the appropriate SQLSRV/PDO_SQLSRV drivers and, since the location of the PHP install is known, edits the php.ini file to enable the SQL Server drivers. This makes installation via WPI extremely easy even for novices.

The enhanced installer now includes two important features leveraging the capabilities offered by the Windows Installer infrastructure.

  1. Upgrades: the installer now supports Upgrades, thus providing a seamless experience for installing a newer release of our driver over an older installation. Upgrades are supported from released versions of the driver only - that is, only upgrades from v1.1. v2.0 CTP1 installs are not supported due to some incompatibilities, so when the new installer detects an install of v2.0 CTP1 then the install is aborted and a failure returned. Since our recommendation for CTPs is to deploy on test systems only, we decided to keep the code simple and require manual uninstallation of v2.0 CTP1. We proactively warn the user of this pre-requisite condition in WPI when the v2.0 CTP2 option is selected, but also added the check in the installer just in case one does not notice it.
  2. Repairs: the installer now supports Repairs - just in case something goes awry after the initial install/upgrade. All one has to do is go to Control Panel –> Program & Features, select the SQL Server Driver for PHP 2.0 and click the Repair button. A small feature, but most appreciated when something goes south and the Repair puts the component back into initial install state.

Now that we have completed these features for our installer, we have published our CTP2 binaries in WPI. At this time, the PHP applications supporting SQL Server published in WPI have not been updated to link to our CTP2 binaries, so one will have to install CTP2 manually after the application is installed.

So how does one install our CTP2 in WPI?
Simple. Just download/install/run WPI, select the Web Platform tab, click the Customize link in the Database section, and check off Microsoft SQL Server Driver for PHP 2.0 CTP2, then click the Install button.

Regarding the CTP2 drivers themselves, we have received positive feedback on CTP2 with only a few issues reported to date. While we continue to address these issues, the good news is that these issues were not introduced by our code re-architecture or design changes in CTP2. In addition, we have received positive responses to our design changes in PDO_SQLSRV driver. While this is certainly good news, we continue to actively monitor the forums and investigate issues reported.

We are working thru the last set of bugs and expect closure on them soon. So, this is the right time for all to download and install our CTP2 driver immediately, hammer away at them, and report failures/regressions on our forum.


Comments (5)

  1. Pierre says:

    There is no VC9 support in 5.2. The WPI uses the binaries which are built using VC6.

    Thanks for the updates btw 🙂

  2. Raymond says:

    I'm glad to see that PDO support will be added in 2.0 but I would also like to see an attribute that allows date fields to be returned as strings and not as DateObjects. This will make things easier when converting from another database that returns date columns as strings.

    The attribue could be called PDO::ATTR_STRINGIFY_DATE_FETCHES or  PDO::ATTR_DATE_STRING

  3. Raymond-

    I think the PDO extension *does* return dates as strings. This is from the documentation: "When using the PDO extension, dates are returned as strings. PDO has no datetime type."

    Is it having the option that is most important to you, or actually getting dates as strings?


  4. Brian is correct. We do note this in our documentation for ReturnDatesAsStrings connection option.

    While the SQLSRV driver defaults to DateTime objects and provides the developer the option to receive them as strings using the ReturnDatesAsStrings connection option, we are responding to the feedback received for the PDO_SQLSRV driver to default to strings for datetime.

    As we've said in a previous response to your comment of keeping with the "traditional PDO design", we did our best to work within the guidelines, intent and prevailing precedents. By returning datetime as strings by default, we feel we've achieved the goal of meeting the needs without extending PDO with a custom driver attribute.

    Question is: do you want/need them to be returned as objects by our PDO_SQLSRV driver?

    We are NOT changing the default for the SQLSRV driver as this is a breaking change for those that depend on this default.

  5. Raymond says:

    Thanks guys.

    I'm glad to hear that the PDO driver defaults to string for date/time columns.  

    Keep up the good work.

Skip to main content