Re: OCI8 broken in CGI, but works in ISAPI?

Koos, Well, I admit, you've got me at a loss. I'll put in my further ideas below, but don't know how much they may help at this point. One thing to try (if you want to take this route) - upgrade to oracle client 8.1.6, and use the pre-compiled binaries from www.php4win.de (as I know these work correctly). Use the same oracle service definitions and see what happens then. If it works, then it might have been something either in the oracle client specifics, or in the compile. And if it doesn't work, then you're no worse off, right? Anyway, your choice. Like I said, some simpler ideas below... Koos Vriezen wrote: > My client is 8.1.5. But I compiled PHP myself and linked the oci modules > against the library from this version. A question for php_oci8 creators might be... "what client version was the extension intended for?" Don't know if that will make any difference. > MYSERVICE.INTERN = > (DESCRIPTION = > (ADDRESS_LIST = > (ADDRESS = (PROTOCOL = TCP)(HOST = londen.intern)(PORT = 1521)) > ) > (CONNECT_DATA = > (SID = orcl) > ) > ) When defining tns entries, I recall some other people having difficulties when the service was not named like "MYSERVICE.WORLD"... though as long as the ".WORLD" or ".INTERN" matches the default domain specified in the Oracle Names tab of your Local Profile (in Net8 Assistant) then I suppose it wouldn't matter. I do remember personally that when I had a different domain suffix specified in my service definition than my default domain, I got error "could not resolve service name", when using the php_oci8 extension - even though a Net8 test of the connection worked fine. If the default domain and the suffix in your tns entry match (either ".WORLD" or ".INTERN"), then php_oci8 can connect okay. Also, try specifying the IP address of the database server instead of a dns name... 123.123.123.123 instead of londen.intern and see what happens. > I still think it's strange. > CGI version: php.exe, php4ts.dll, php_oci8.dll and DLL from oracle > ISAPI module: php4isapi.dll, php4ts.dll, php_oci8.dll and DLL from oracle > php.exe or php4isapi.dll should initialize php and pass the script to > php4ts.dll. IMHO one of them (probably php.exe) is doing something wrong. > PHP3's CGI version also have no problem so does SQLPLUS.EXE. I believe the BIGGEST difference in CGI vs. SAPI (server api) is in how each processes system environment information. At least, that's what I've seen between CGI and Apache Module. As far as the code that get's run, it's almost exactly the same, but system information is accessed differently depending on which way you're running. And that's just a hunch, don't take my word for it :) Hope some of that helps... the best thing I would say is the Net8 domain specifications... try changing your default domain to "INTERN" (if it's not set that way already) and see whether that makes a difference. -- Andy Hoffman Web Developer Bristol-Myers Squibb email: andy.hoffman@bms.com