MySql not enable from IIS but worksfrom Command line -- wi..

Problem: MySQL library bound ONLY when PHP is run from the
command prompt, and NOT when PHP is run from an IIS Web page.
(Error indicates that mysql_connect is an unknown function.)

Not only does the library bind from the command prompt but data is
retrieved using the EXACT same program file that fails under IIS.

(Terrible) Solution: Created a Hardlink from %SystemRoot%\php.ini
to the "real" php.ini in the PHP directory which was on the path -- this
is unnecessary on other systems with similar configuration.

Environment:
Microsoft(R) Windows(R) Server 2003, Standard Edition
5.2.3790 Service Pack 2 Build 3790
IIS 6 -- ISAPI dll version of PHP

PHP 5.2.4 (cli) (built: Aug 30 2007 07:06:31)
Build Date Aug 30 2007 07:05:48
Server API ISAPI Virtual Directory Support enabled
Configuration File (php.ini) Path C:\WINDOWS
Loaded Configuration File (none) PHP API 20041225

PHP.ini SHOULD be found in the PHP directory or on the path (it's
both) and it should NOT be necessary to place it in the Windows (SystemRoot)
directory.

The Hardlink does avoid the possibility of editing the "wrong" one but is an
ugly kludge.

fsutil hardlink create "%systemroot%\php.ini" c:\php\php.ini

(adjust for PHP directory if different, e.g., C:\Program Files\PHP
etc....)

Possibilities that didn't fix the problem:

1) Permissions on the php.ini or on the ext\*.dll s -- since it works
from the
command line this is run as a "local user" (an Admin mostly) and IIS runs
the
program as the "anonymous IIS" user (by default). Changing this didn't
help.

2) Checking to ensure that the php_mysql.dll and the correct extension
path
was in the php.ini file -- this was correct and remember that everything
works
when the file is run from the command prompt with the SAME (only) INI file.

3) Checking to make sure there weren't mutliple copies of the dll or the
libmysql.dll;
there was a byte for byte identical libmysql.dll in the MySQL bin directory
but
(either) renaming it or the one in the PHP directory provided no help.

4) Some weirdness in the PHP5Isapi.dll which is not present when the
PHP.exe
is run -- this pretty much seems to be the problem even though I haven't
solved
it this way.

Also, during every attempt to fix the problem the IIS Admin service was
halted
(this stops the WWW service also) and then the WWW service was restarted
(which restarts the Admin service automatically.)

Only the 'addition' of the Windows directory php.ini file helped.

I am still looking for ideas but also wanted to post this for others who are
having problems.

--
Herb