I'm running PHP 5.3.1 on IIS 7.5 on Windows 7 Ultimate x64. I've been trying to make PHP connect to my local installation of SQL Server 2008 Express over ODBC using ADODB. At first I had trouble getting it to connect, because even after I added my local SQL server as a server DSN in the ODBC manager, I kept getting this error:
[Microsoft][ODBC Driver Manager] The specified DSN contains an
architecture mismatch between the Driver and Application
I asked about this on Stack Overflow and got an answer. In retrospect I probably should have asked that here, but I got my answer so I don't care. (Plus I absolutely loathe the fact that the trilogy sites are split in the first place, but that's another story...)
Anyways, after setting up the data source using %windir%\sysWOW64\odbcad32.exe instead, I seemed to make some progress. I am no longer getting that error I listed above. Instead, I am getting a seemingly much more evil error, namely this one:
Before I was just getting a simple PHP exception. Now my PHP script does the equivalent of segfaulting because it's apparently getting hung up on this 64-bit ODBC driver. Help! Connecting to a SQL Server should be a relatively simple and straight-forward task, so what do I need to do to get things working?
UPDATE: I'm starting a bounty because I really need to get SQL Server and PHP talking to each other soon. One poster suggested I check the Event Log, but that shows nothing, and another poster suggested I enable Failed Request Tracing, which I have done but I'm not so sure it provides anything telling. A copy of the error trace it provides can be found here (IE-only). I also have the (very basic) PHP script shown here. I've changed the name of the connection to "MYCOMPUTER," changed the name of the specific database/catalog to "MyDatabase," and hidden the password, but made no other changes.
A little background:
- My computer is called MYCOMPUTER (not really, but think of it that way)
- MYCOMPUTER is running 64-bit Windows 7 Ultimate with IIS 7.5
- MYCOMPUTER has PHP 5.3.1 installed (32-bit) handled through FastCGI
- MYCOMPUTER has 64-bit SQL Server Express 2008 installed
- The default SQL instance is called MYCOMPUTER\SQLEXPRESS
- There is a database called MyDatabase (again, the name is actually different)
- There is a System DSN set up called MYCOMPUTER (set up with the 32-bit ODBC Manager)
- There is a System DSN set up called MYCOMPUTER64 (set up with the 64-bit ODBC Manager)
If I try to connect to MYCOMPUTER in that script I linked to, I get that big scary 500 error. If I try to connect to MYCOMPUTER64 in that same script, I get the "architecture mismatch" error listed above. Either way it's not working. I need it to work. Please help.
I find that if you look at PHP+ODBC the wrong way when using IIS7 it gives you a generic 500. Getting a 500 error of "0" is extra fun.
I have this feeling you're approaching this from the OS/IIS side when doing it from the PHP code-side may lead us to the fault faster (now that you got your driver issue figured out).
Does PHPInfo work as expected?
Out of the referenced PHP script, what line is it failing at? If you have no other way, just comment out everything inside the PHP tags, see if it works to give you a blank page; then un-comment lines and code sections (inner-most nesting last) one at a time until you find the one that causes the fault to be thrown.
Since your test script is short it'll be easy, and hopfully it'll point out the next thing to check.
HTH.
Have you made sure to Enable 32-Bit Applications? This can be found in the app pool for your site under Advanced Settings -> General.
500 - Internal Server Error is a very generic error and means there is some issue with the server configuration. The Error Code: 0x00000000 means "No Error", you can enable Failed Request Tracing on the Web site and check what is causing the issue.
It looks that the PHP handler doesn't work. Did you check the PHP extension handler in your http handler setting? Please also check the permission of your PHP handler.
I've sen advice elsewhere, to use this command to make IIS run as 32-bit --
-- but I cannot attest to its efficacy.
I do recommend not naming everything identically. It can be very difficult to figure out which MYCOMPUTER produces an error, for instance...
The earlier suggestion to review PHPinfo output is a good one. This will prove whether PHP is working, before it gets to the ODBC interaction.
Why are you using ODBC and a DSN instead of PHP's native SQL Server driver?
That's the worst thing you can do when connecting to a SQL Server database.