Ho avuto la necessità di scrivere del codice per recuperare ed elaborare dei dati presenti su una tabella di un SQL Server di Microsoft da codice PHP girante tuttavia (almeno in produzione) su una macchina Linux.
Il mio ambiente di sviluppo è però configurato come segue:
Lo scopo del codice PHP era quello di recuperare dei dati dall’SQL Express e utilizzarli per altre elaborazioni.
Di seguito i passi fatti per ottenere questo.
Scaricare il file .tar da questo link: https://github.com/microsoft/msphpsql/releases/download/v5.7.1-preview/Mac-7.3.tar
Espandete il file .tar, ne viene generata una cartella contenente alcuni file (ci sono le versioni PDO e standard, in formato Thread Safe e Non Thread Safe).
Controllate sul vostro phpinfo() se avete bisogno delle versioni TS o NTS. Lo determinata cercando la voce “thread safety“: se è configurata come “disabled” vi servono le NTS e viceversa.
Stabilito questo, i file .so e .signature relativi vanno copiati nella cartella delle estensioni di PHP. Anch’essa può essere determinata dal phpinfo(), alla voce “extension_dir”.
Fatto questo, bisogna istruire php a utilizzare l’estensione apposita appena copiata.
Bisogna quindi editare il file php.ini (il cui percorso ancora una volta va determinato attraverso il phpinfo alla voce “Loaded configuration file“) e aggiungere in un punto qualsiasi (ma per essere un minimo ordinati, io l’ho messo in coda a tutte le altre righe dello stesso tipo) la seguente riga:
extension="php_sqlsrv_73_nts.so"
extension="php_pdo_sqlsrv_73_nts.so"
La prima riga abiliterà l’estensione SQLSRV, mentre la seconda la variante di PDO che permette appunto l’interrogazione di SQL Server. Non sono correlate tra loro, le potete usare entrambe o solo una delle due come vi serve. Evidentemente poi, il codice dovrà far riferimento a quella effettivamente richiamata dalla configurazione.
A questo punto possiamo riavviare apache con
sudo apachectl restart
e la prima fase è fatta.
Sembrava facile… invece no. I driver di cui sopra non sono in realtà veri driver, ossia non interrogano nativamente SQLServer, ma sono in realtà dei miserabili wrapper del driver ODBC (ebbene sì, facciamo un salto indietro nel passato di quasi un ventennio) che va anch’esso installato, altrimenti i succitati “driver” fanno assai poco (ossia niente).
A questo link: https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver15#macos potete trovare le istruzioni per l’installazione di tali driver. Il tutto avviene mediante l’utilizzo del famigerato package manager Homebrew. Se l’avete già installato, potete usare tranquillamente solo l’ultima riga dei comandi mostrati sul sito Microsoft.
Funziona ora?
Ancora no, siamo distanti dal risultato…. gosh Batman.
Passiamo ora al lato Microsoft della cosa. Se abbiamo fatto un’installazione standard lasciando tutte le configurazioni sui valori di default non sarà possibile connettersi al nostro SQL Server, anche in presenza di tutti i requisiti lato PHP.
Questo perchè normalmente SQL Server Express non prevede di default di essere interrogato da connessioni remote.
I passi da fare sono:
Questa è la fase che mi ha fatto dannare di più, stavo per rinunciare, davvero. Il problema che si presentava era che al tentativo di connessione, il driver si lamentava della mancanza di OpenSSL e di assicurarsi che fossero installate le versioni 1.0 o 1.1. Niente di più strano, sul MAC difatti tutto regolare, openssl era perfettamente disponibile sul path.
Lo spunto è arrivato da questo articolo: https://github.com/microsoft/homebrew-mssql-release/issues/37
In particolar modo, l’ultimo post della discussione lamentava l’assenza di una particolare cartella. Vado a controllare pure io e… bingo! Ecco la rogna!
Homebrew ha creato un symlink alla cartella dove effettivamente ha installato l’openSSL come dipendenza del driver ODBC (vi risparmio un trattato su come funziona Homebrew, ma sostanzialmente lui si crea un suo ambiente di lavoro isolato dal resto del MAC dove si mette tutte le sue brave dipendenze), ma il nome della cartella sicuramente non era quello che il driver si aspettava.
La cartella infatti si chiama “OpenSSL@1.1“. Chiaramente ho intuito che il driver Microsoft mai più avrebbe accettato un nome simile. Controllato quindi con
ls -all
l’effettivo symlink, ne ho creato un altro alla stessa cartella vista col precedente comando ma chiamato semplicemente “openssl”, senza la decorazione della versione.
Ecco fatto, un pomeriggio di sudori freddi, ma spero sia utile anche a qualcuno la fuori.