Actually, I should say “I hate open source as only someone that has used open source software could hate it.”
Today I spent the better part of the day trying to get my newest installation of Ubuntu 8.10 to talk to our Sybase and MS SQL Servers from PHP. Not only that, but I need to be able to handle multiple result sets from Sybase and I cannot use PDO since it has never, ever worked correctly when trying to connect to Sybase using the native drivers. And there is no way in hell I am using ODBC to connect to our Sybase servers (why should I have to when I can use native Sybase connectivity?).
So with this in mind I set out to tap into the ease of use of Ubuntu as an operating system and installed php-sybase using the Synaptic Package Manager. That was my first, and probably biggest mistake in the whole of this ordeal. Apparently the package maintainers for Ubuntu decided that when installing the php-sybase extension they would actually install the php-mssql extension and map all the sybase function names to the mssql function names. That is just stupid. Here is why:
The common functions between php-mssql and php-sybase in the Ubuntu package
| Function purpose |
sybase_* |
mssql_* |
| Based upon the PHP manual as of February 11, 2009 |
| connect |
sybase_connect |
mssql_connect |
| persistent connect |
sybase_pconnect |
mssql_pconnect |
| select database |
sybase_select_db |
mssql_select_db |
| query |
sybase_query |
mssql_query |
| result (cell) |
sybase_result |
mssql_result |
| result (row – numeric index) |
sybase_fetch_row |
mssql_fetch_row |
| result (row – associative index) |
sybase_fetch_assoc |
mssql_fetch_assoc |
| result (row – both index) |
sybase_fetch_array |
mssql_fetch_array |
| result (row – object) |
sybase_fetch_object |
mssql_fetch_object |
| result (row count – data sets) |
sybase_num_rows |
mssql_num_rows |
| result (row count – affected rows) |
sybase_affected_rows |
mssql_rows_affected |
| result (row pointer mover) |
sybase_data_seek |
mssql_data_seek |
| result (field count) |
sybase_num_fields |
mssql_num_fields |
| result (field info) |
sybase_fetch_field |
mssql_fetch_field |
| result (field pointer mover) |
sybase_field_seek |
mssql_field_seek |
| result (remove from memory) |
sybase_free_result |
mssql_free_result |
| errors |
sybase_get_last_message |
mssql_get_last_message |
| close |
sybase_close |
mssql_close |
| setting (message severity) |
sybase_min_message_severity |
mssql_min_message_severity |
| setting (error severity) |
sybase_min_error_severity |
mssql_min_error_severity |
You can see in this common table that almost all of the mssql_* functions that share a common purpose with the sybase_* functions are the same, save for one glaring exception (rows_affected? Seriously?). The problem lies in the fact that there are a ton of mssql_* functions that do not have a matching function in the sybase_* family of functions according to the manual. Those functions are:
- mssql_init
- mssql_bind
- mssql_execute
- mssql_next_result
- mssql_field_length
- mssql_field_name
- mssql_field_type
- mssql_free_statement
- mssql_fetch_batch
- mssql_guid_string
Throw into this mix that there are a few sybase_* functions that do not have a corresponding mssql_* function, such as:
- sybase_deadlock_retry_count
- sybase_min_client_severity
- sybase_min_server_severity
- sybase_set_message_handler
- sybase_unbuffered_query
And you can see that building the Sybase extension from the SQL Server extension will not work under normal circumstances if you have your code built around the functions in the manual. So… it was back to the drawing board. And this drawing board is way different than the last one I remember (think back to building the sybase and mssql extension for PHP in Fedora).
What this ended up boiling down to was that I had to compile a PHP 4 hacked version of the Sybase extension source code that offered handling of multiple result sets. Not that it was that entirely stupid to do, except for the fact that the client package I needed to compile against was in Red Hat RPM format. But thanks to the Alien package converter tool I was able to install the Sybase client on Ubuntu with little headache.
Building the Sybase extension was not that big of a deal either once the client was installed. But getting the SQL Server extension built has been a pain in the rump still yet.
The first thing I had to do was build the FreeTDS package from source since the Ubuntu pacakge installer installs the freetds libraries somewhere but they are really nowhere to be found. And since you need to build them in a way that allows for dblib use I had to build from source with build flags. So I got the freetds package installed, after a few tries, and then went to build the sql server extension from source.
And it looked like it worked. But when I restarted Apache I realized it hadn’t worked. You know why? Because the stupid source code for the mssql extension aliases all the sybase extensions WITHOUT checking to see if Sybase is already compiled. Whiskey Tango Foxtrot?
So I had to comment out the aliasing part of the extension source code that rewrites the sybase extension and compile again. And this time it worked. Except for some reason, even though I am editing the freetds.conf file the server I am trying to connect to is not resolving properly. And I have no idea why.
So here I am, pissed off at open source, Linux, Ubuntu, PHP, penguins and all things cute and cuddly. I know I will get it to work. And I know when I do I will be making sounds in my cubicle that will make my coworkers hand me tissues because they will think I need to clean up after myself. But for now, I hate open source. But only as once who spends a lot of time in it.