I had one of those situations today that I think every person working with IT experiences from time to time. I had a problem that took 4 hours to resolve. Once resolved I realized that doing the right things in the right order (and also memorizing a little better) could have saved me 3 hours and 55 minutes.
The problem was related to SQLyog HTTP-tunneling. When new PHP versions are released it is most often me that verifies that our HTTP tunneling is not broken. Thus I have followed the PHP 5.3 release cycle from early betas to RC and GA and experienced that very early PHP 5.3.0 beta releases did not work with our HTTP-tunnel. However as both 5.3.0 RC and 5.3.0 GA worked fine (as every 5.2.x always did) I executed “SET panic = OFF” against my most important system (old but still a little functional!).
However the panic reoccurred when PHP 5.3.1 was released. Nothing worked from PHP. I sat for a couple of hours with a colleague. Small and very simple PHP test applications did not work with PHP 5.3.1 either on my environment (but worked fine on my PHP 5.2.11 and 5.3.0 configurations). Not a single comma was added to the MySQL general log or error when trying to connect from PHP 5.3.1. The client application hang for considerable time and finally came out with an error that the URL to the PHP script could not be found. Even more frustrating: the test applications and SQLyog/HTTP-tunnel worked fine on another machine with a(should be) identical configuration in Webyog office as well. Needless to say any connection not using PHP also worked fine.
We are aware that some functions in PHP are depreciated in 5.3.x (and will be removed in PHP 6 according to plans). This may cause problems with our current tunneler on some systems with PHP 5.3.1. But we have the fix ready to be released with next SQLyog release (and anybody experiencing such problems can contact us for an updated tunneler). But as 5.3.0 was not affected this was obviously not the problem occurring on my system. It was something else.
We agreed that I should try reinstalling MySQL and Apache from scratch on my system. However before doing so I ran the queries:
SELECT VERSION(); — returned ’5.1.36-log’
SHOW ENGINES; — returned PBXT as one engine available in addition to the engines from MySQL … hhmmmm …
Now I got it! I remember now that this particular server on this particular system of mine was a forked build with the PBXT engine downloaded from Primebase website. Installing the standard/official MySQL 5.1.41 solved the problem immediately. PHP 5.3.1 (and thus SQLyog/HTTP-tunnel) connect like a charm.
I am not able to tell what the problem with this server and PHP version is in technical terms. And probably this server is also now historical so it is probably not very important either now. But I think Primebase, the MariaDB people, the XAMPP distributors (and everybody building MySQL with PBXT) as well as the PHP developer team should know this issue and try to figure it out (as well as test with their recent builds and PHP 5.3.1), so that it will not happen again. A forked build should not only work with the (command line) clients shipped with the server but the tools and connectors used by people already.
… (and besides the version string ’5.1.36-log’ is definitely not good enough for a forked server build).