2

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:

Click to enlarge

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.

soapergem
  • 719
  • 4
  • 13
  • 29

6 Answers6

2

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.

techie007
  • 1,892
  • 17
  • 24
  • 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 Jan 21 '10 at 07:02
  • 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! – techie007 Jan 21 '10 at 21:15
1

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

palehorse
  • 4,179
  • 5
  • 28
  • 27
  • I enabled this but am still getting the same error as before. – soapergem Dec 28 '09 at 07:48
  • Do you find anything in the event log that may contain a little more information? – palehorse Dec 28 '09 at 16:08
  • 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 Jan 18 '10 at 19:26
  • 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. – palehorse Jan 19 '10 at 15:19
0

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.

sky100
  • 504
  • 2
  • 3
  • 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 Jan 21 '10 at 06:52
0

I've sen advice elsewhere, to use this command to make IIS run as 32-bit --

   cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

-- 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.

0

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.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • The "worst" thing? Um, citation needed? – soapergem Jan 21 '10 at 07:02
  • 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. – Massimo Jan 21 '10 at 08:49
  • 1
    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. – soapergem Jan 22 '10 at 20:41
0

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.

Vivek Kumbhar
  • 3,063
  • 1
  • 17
  • 13
  • 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. – soapergem Jan 18 '10 at 19:27