Why am I getting this 500 error from IIS?

Question

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.

Solution 1

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.

Solution 2

Have you made sure to Enable 32-Bit Applications? This can be found in the app pool for your site under Advanced Settings -> General.

Comments

[soapergem]

I enabled this but am still getting the same error as before.

[soapergem]

Nothing in the event log at all. I enabled Failed Request Tracing and posted a link to the error XML it generated in the main description above.

[soapergem]

I enabled FRT like you suggested but it didn't seem to reveal anything of value, at least as far as I could tell. I posted a link to the error XML it generated in the main description above if you'd like to take a look.

[palehorse]

That's odd. Normally when I see a 500 I get a little more info in the event log. How did you install php and FastCGI? If you did not use the Web Platform INstaller, you may try uninstalling them and reinstall to make sure all dependencies (including the Microsoft SQL Server Driver for PHP) is there. One other thing you could do is try not using a DSN, but rather building the connection string directly.

[soapergem]

Wrong; the PHP handler is working fine. If it wasn't I wouldn't be getting the error, nor would I be able to run phpinfo(). The only issue is when I try to connect to ODBC.

[soapergem]

Wow I feel like a HUGE idiot. I was definitely over-complicating the problem. So here's what happened: the problem was on line 12, where I run the SQL command "USE [MyDatabase]". I had a typo in the spelling of the database name. That's all. As such, that database didn't exist, so the SQL statement failed, and because I had included the adodb-exceptions file, the failed SQL execute meant it threw an (uncaught) exception. Thanks for your simple advice; it's what guided me to discover the problem, and how much of an idiot I am.

[soapergem]

The "worst" thing? Um, citation needed?

[Massimo]

ODBC is a generic protocol to access any data source; it's not optimized for any particular DBMS. Native SQL Server drivers are designed to talk with SQL Server DBs, and so can perform a lot better. The same is true for any specific driver (Oracle, MySQL, etc.) opposed to ODBC. ODBC should be used only when a specific driver is unavailable, or if you don't know a priori which data source you'll be connecting to.

[techie007]

I had a feeling it'd be something goofy; as any time I end up with 'unexplainable' 500's it usually becuase I misspelled something or forgot a semicolon. ;) Glad to hear you got it going!

[soapergem]

Hmmm, I never really thought about that. I'm going to have to run some performance tests now to see how much of an impact the native drivers have over ODBC.