We already had PHP and MySQL happily running on Linux. The PHP download for NT was no problem and after telling the SQL Server installation that it had to be prepared to speak TCP/IP to clients (an option buried amongst the numerous dialog boxes), it was responding to local requests from PHP too. We persuaded the PHP code to talk across our network to MySQL without the slightest difficulty. The reverse was another matter.

Building a version of PHP that would run on Linux and talk to SQL Server was not proving to be easy. After quite a lot of digging around the PHP website and reading what various people had to say in mailing lists, we'd found that a) SQL Server talks the same protocol as Sybase (no surprise, since SQL Server is/was based on a Sybase core) and that b) we would need some special libraries to make it work. Those libraries are not part of standard PHP distributions for Linux/Unix. We chose to use the freetds library.

It took a lot of cursing and sweating to get PHP working with freetds - we'd have been well advised to have spent our time looking around for the guidance that is actually out there, but sadly hadn't found it first time around. At least one useful starting point is: Michael Peceny's site and of course, after all the struggling, others came to light as well. You do need to be happy compiling applications from source to make it work. If there are any packaged installations of PHP and freetds, then we didn't find them.

Eventually PHP4 running on Linux was talking to SQL Server running on NT.

Being used to the mature and powerful Perl DBI:: interface for accessing databases, PHP's insistence on using a different set of function calls per database seemed terribly retrograde. Whilst there are probably thousands of similar solutions to what we did (and most of them probably better), we built our own extremely simple interface so that the bulk of the software wouldn't have to call functions conditionally depending on the target database.