Re: WORKING!! :) oci8 & apache mod (4.0.2 release) -
| From: | Andy Hoffman | Date: | Tue, 05 Sep 2000 21:00:45 +0000 |
| Subject: | Re: WORKING!! :) oci8 & apache mod (4.0.2 release) - | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.windows |
| Request: | Send a blank email to php-windows+get-2437@lists.php.net to get a copy of this message | ||
Daniel Beulshausen wrote:
> no worries :) i'll have a look at the oracle technet maybe they're stored
> there somewhere.
> but i still think this has something to do with the directory support...
Solved It!!!!!!
Apache 3.1.12 & PHP4.0.2 Release working as Apache module with oci8 support!
Teehee... man that was a tough one.
One more thing to look out for is your setting of "extension_dir". If you
don't set this in the correct FORMAT, then oci8 will kill apache service on
load. Very odd, but anyway, here's what happened in debuggin today...
**** My original mail which I was writing as I tested stuff, but solved
before sending ***
OK, moving this a step further... after fighting for a day-or-so on trying to
OVERRIDE apache's path environment, and getting nowhere (I can't seem to get
this service to start with my own specified PATH value... hmmmm), I decided
to try something else. First, as soon as I uncomment (add) php_oci8.dll in
php.ini and restart apache service, crash with non-specific "service not
responding to control function" error.
Keeping php as apache module, I decided to MOVE my copies of oci.dll and
ociw32.dll from c:\oracle\ora81\bin to a different non-pathed directory -
just to see if Apache would find them, or if the error messages would change
on startup of the apache service. And they did... with oci.dll OUTSIDE the
computer's specified path (which apache is still seeing as
"c:\oracle\ora81\bin;<therest>") Apache gives the following messages 1)
standard LONG message of "Could not locate OCI.dll in path <all of my system
path which is quite long referenced with backslashes>" and 2) short message
(from php) of "Unable to load dynamic library '\php\extensions/php_oci8.dll'
- The specified module could not be found." Two odd things though: 1) why
does this message show backslashes for the first two directories and then a
frontslash in front of the extension, and 2) I get the same sequence of two
dialogs THREE TIMES for the same "OCI.dll" - any clue why it might issue this
3 times? However, the service continues to load at this point without the
php_oci8 support.
Next, move oci.dll BACK into system pathed oracle directory, and crash... it
didn't even get to the point of looking for ociw32.dll.
***** end of the message I WAS composing :) ****
So, the one thing I thought to try was look at my "extension_dir" setting in
php.ini, and indeed IT was set to the odd "\php\extensions" instead of
"c:/php/extensions" as Daniel originally had it in php-ini.dist. Duh! So,
on a hunch I reset the extension_dir setting to "c:/php/extensions/", with
php_oci8 included in my extensions section, then restarted apache as service
with php module and... drum roll... everything worked!
Thus another KEY FACTOR in php4/apache/oci8 support is having ALL
front-slashes in your php.ini settings... doesn't matter what the external
PATH is (as long as apache & php can see your oci8 dlls) but you MUST have
front-slashes in your extension dir settings or kaboom!
Now I'm going home, as I think that was enough of an accomplishment today.
So, just to prove that it is possible... I've got the following running
(cool!)
php4.0.2 release (php4win.de binaries & extensions)
apache 3.1.12 loading php4apache.dll (from above release)
Zend Optimizer .99 for php4.0.2
php_oci8 extension loading with Oracle 8.1.6 Client
Man that took a lot, but worth it. I'll write that all down sometime this
week.
--
Andy Hoffman
Web Developer
Bristol-Myers Squibb
email: andy.hoffman@bms.com