Actuellement en train de tester une migration vers PHP7 (depuis PHP5.5), j’ai pu constater que la gestion des connexions à SQL Server via les fonctions natives (mssql_) disparaissait. Utilisant des connexions à MySQL et à SQL Server au travers de nos applications PHP, j’ai donc du me pencher sur la question pour voir quels étaient les solutions possibles pour remplacer ces fonctions natives.
Migration PHP7
PHP7 est sorti depuis maintenant plusieurs mois, et est intégré par défaut par exemple dans Ubuntu 16.04. Nous avons donc décidé de tester une migration de Ubuntu 14.04 vers Ubuntu 16.04, avec une migration vers PHP7. Nous avons été convaincus entre autres par des benchmarks très flatteurs pour PHP7 et également par des nouveautés très interessantes de PHP7 au niveau des possibilités de typage.
Autre point également, la migration vers PHP7 est normalement assez simple. La principale évolution concerne la refonte du moteur en profondeur pour une amélioration de la performance.
Disparition des fonctions natives SQL Server
Peu de choses changent avec cette migration vers PHP7, mais en regardant la documentation officielle on voit que disparaissent un certain nombre d’extensions, dont les fonctions mssql. Pour les autres, comme ereg et mysql, elles étaient déjà deprecated depuis plusieurs versions.
Ces fonctions mssql permettent de se connecter et de lancer des requêtes ou procédures stockées sur un serveur SQL Server. Dans notre cas, c’est très utile car nous avons des bases MySQL et également des bases SQL Server. C’est donc un point qui peut être bloquants pour nous si jamais nous ne trouvons pas d’équivalent.
Pistes de remplacement
Si on regarder la documentation officielle, par exemple celle de la fonction mssql_connect, on voit que 3 options sont possibles :
- Passer par PDO
- Utiliser la fonction sqlsrv_connect
- Passer par de l’ODBC
Dans tous les cas, c’est plus contraignant que des fonctions natives. Car avec PDO il faudra passer par un pilote ODBC (donc cela rejoint la solution 3).Enfin, sqlsrv_connect s’installe en environnement Windows (DLL sous IIS).
La conclusion est donc que quel que soit la solution retenue, elle sera de toute façon plus contraignante qu’une solution purement native. Après, l’idée est maintenant de faire en sorte que cela soit le plus transparent possible. Et le plus stable possible aussi, car il s’agit d’un environnement de production.
En continuant mes recherches, je suis tombé sur un package, maintenu par Meet Bhagdev, qui permet d’avoir un tout-en-un qui semble intéressant. C’est disponible sur un github.
L’installation n’est pas très compliquée. Sur une installation fonctionnelle, avec déjà Apache et PHP, cela revient à récupérer les bons paquets, le gestionnaire ODBC, et les extensions pour PHP.
En résumé, voici les commandes que j’ai eu à lancer (sur Ubuntu 16.04 donc) :
wget https://github.com/Microsoft/msphpsql/blob/PHP-7.0-Linux/ODBC%20install%20scripts/installodbc_ubuntu.sh sudo sh installodbc_ubuntu.sh sudo apt-get install php libapache2-mod-php sudo apt-get install php-pear php-dev sudo pecl search sqlsrv sudo pecl install sqlsrv-4.0.5 sudo pecl install pdo_sqlsrv-4.0.5
Cela a pour effet de mettre en place une extension PHP, avec tout ce qu’il faut pour communiquer avec un serveur SQL Server.
La dernière chose à faire était donc d’activer l’extension dans le php.ini en ajoutant ces lignes :
[SQLServer] extension=/usr/lib/php/20151012/sqlsrv.so
Et le tour était joué.
Cela donne ensuite accès, sous Linux, aux différentes fonctions sqlsrv_ qui sont décrites dans la documentation. Cela fonctionnera de la même manière que sur un IIS.
Par exemple, pour une connexion à un serveur SQL Server :
$connectionInfo = array( "Database"=>$this->dbname, "UID"=>$this->dbuser, "PWD"=>$this->dbpass); $this->sqlLink = sqlsrv_connect( $this->dbhost, $connectionInfo);
Suite des tests
Pour l’instant, je suis donc parti sur cette solution.
Elle semble très bien, mais je n’ai pas encore fini mes différents tests. En tout cas, j’ai pu appeler des requêtes, mettre à jour des données, lancer des procédures stockées sans problèmes. Je n’ai pas encore testé par exemple des requêtes avec OpenQuery voir ce que cela donnait.
Je mettrai à jour ce post en fonction de la suite de mes tests.
De votre côté, si vous avez d’autres idées ou de meilleures pistes, n’hésitez surtout pas à réagir dans les commentaires ci-dessous.
