I recently upgraded Apache and PHP due to security, and I also use PHP to communicate with Oracle databases. The new PHP version only has php_oci8_12c.dll module, so I also installed Oracle 12c client.
After I enable the oci8 module, I noticed the module doesn't show up in Apache when I run phpinfo(), but if I run php -m, I find the oci8 module there. Further checking revealed that the PATH environment variable has not been updated since the upgrade, and that the new path only get appended at the end of the PATH variable.
I paste below the (stripped-down) PATH data from Apache:
C:\oracle\client11gR2_32\bin;C:\www\Apache24\bin;C:\www\php548;C:\database\mysql5528\bin;C:\oracle12c\client12c_32\bin;C:\www\php562;C:\www\php562\ext
Compared with system PATH variable:
C:\oracle12c\client12c_32\bin;C:\oracle\client11gR2_32\bin;C:\www\Apache24\bin;C:\www\php562;C:\www\php562\ext;C:\database\mysql5528\bin
I tried restarting the Apache service, and also uninstall/reinstall, but none works. It seems that the data somehow get 'cached' in a separate location, but I can't tell where. If I renamed the Oracle client 11g HOME folder, then the oci8 module is detected and loaded in Apache.
I've searched all around the internet for 'resetting' the Apache PATH variable, but to no avail, therefore I post it here. Please help.
There are two possible reasons I can think of:
The path to the 12c client is a user variable, not a system variable (but then I would expect it to be at the end of the path list)
The 12c client installer has directly modified the registry to add the path, and therefore the system environment has not recognised the change yet. (If you are running Apache as a service then just because your account can see the path change doesn't mean the SYSTEM account can see the change.)
Assuming the latter case, a server reboot would fix the problem. If you can't reboot the server then you can try stopping Apache, opening the Environment Variables dialog, and simply pressing OK (on this and all parent dialogs) to 'reinitialise' the system environment. Start Apache again and it should pick up the new setting.
On a related note: You should really replace the bundled OCI driver (1.4.10) with the most recent build from PECL (currently 2.0.8). As stated in the PECL description:
Use the older PHP OCI8 1.4.10 when using PHP 4.3.9
through to PHP 5.1.x, or when only Oracle Database 9.2 client
libraries are available.
The Windows download contains php_oci8.dll, php_oci8_11g.dll, and php_oci8_12c.dll. So you wouldn't have needed to try changing the Oracle client installation.
Related
Hy! I'm trying to use oci on windows, I found some linked issues, but I don't have any xampp, or apache, or anything, I'm only using the php built-in server. I enabled the oci extension in the php.ini file, but it does not work. I was looking for answer. I don't need any oracle database, there is a database, I only want to connect it with my app. I have the error above every time, when I'm trying to run any php command. So it does not work. The missing dll file is there, so I don't understand, why is it missing. I installed pear, and pecl, but pecl installations need openssl, openssl needs visualC++ and some other things... is there any other solution? Even though why does it not find that dll, if it's there... I downloaded Oracle Instant client and Oracle SDK, I unzipped it, set the environmental variables, but nothing changed... Please, help!
You need to download the correct oci8_19.dll if not already there and placed it under your_xampp_directory\php\ext folder.
Enable/add this extension in your php.ini file.
Add environment variable path for PHP.
Then, you also need Oracle Instant client to load/run this properly. Download it from here. Be mindful about x86 or x64 architecture of your windows machine and download the one that matches your machine specs.
Add this Oracle instant client path too in your environment variable.
Restart command prompt and type php -v. Voila! It runs smoothly and shows you just the PHP version, which means your oci extension loaded properly.
We are migrating from a Windows SBS 2011 to Windows Server 2012 R2.
We have an internal website that connects to our Oracle database using PHP.
I am trying to migrate this to the new server and so far I have:
Installed IIS Server Role
Installed PHP
Downloaded Oracle Instant Client to C:\instantclient
Added C:\instantclient to PATH System Variable
Added php_oci8.dll to php.ini and checked that PHP is actually using this php.ini
Restarted server
I am still getting error messages like oci_ commands not being recognised etc.
I'm lost. I've searched online and the instructions match what I have done from memory.
I haven't found a single thing online that I haven't done.
Depending on the version of InstantClient you have installed you might need to include the bin folder in the path, like so:
C:\instantclient\bin
To check if the DLL files are available in the path enter where oci*.dll in a command prompt. It should return a list of matching files.
Also, remember that just because your account can see the DLL files doesn't mean IIS/PHP can. That runs under a different account that might not have permission to access the files. Check your IIS error log and PHP php_errors.log file for any specific error messages.
Edit
After a rather lengthy chat, the problem was resolved by:
Updating the InstantClient from 10.1.0.5 to 10.2.0.5 (as mentioned in the module requirements: On Windows, the php_oci8 DLL needs Oracle client libraries from version 10gR2 or greater.)
Adding a copy of msvcr71.dll to the InstantClient folder.
Downloading and manually configuring PHP from php.net instead of using PHP Manager for IIS.
Ensuring the Path environment variable correctly pointed to the InstantClient and PHP folders.
try this:
extension=php_oci8_12c.dll
(instead of php_oci8.dll) - that is what I am using and you probably downloaded the same instant client as I did.
I've set up a Fedora 19 server, with Oracle 11g, PHP 5.5.4, Apache 2.4.6, and PEAR 1.9.4. In addition to this, I have the OCI8 plug-in for PHP downloaded and enabled, and have downloaded MDB2 and the MDB2_Driver_oci8.
However, there are problems with the setup - an old website from an older server doesn't work on it, so it seems the culprit is an improperly setup Oracle environment for Apache, and oci8.
The Oracle 11g Database itself, however, works fine - I've been able to log in as SYSTEM, create a new user, and restore a database to said user.
Below is a screenshot from the Environment of the new Fedora 19 server, using phpinfo():
Below is a screenshot of the Environment of the older Fedora server:
There's a lot, but probably the only important things there are the ones concerning Oracle.
I followed link here tutorial on how to install Oracle 11g on Fedora, and I was able to get it up and running, albeit I have to run . /u01/app/oracle/product/11.2.0/xe/bin/oracle_env.sh every time I start up.
But whereas in the old server, it shows up in the Environment (in phpinfo()), in the new server, it does not.
Of note is that LD_LIBRARY_PATH is set in both, but I had to to add it manually in the httpd file (/etc/sysconfig/) by adding the following in it:
LD_LIBRARY_PATH="/u01/apps/oracle/product/11.2.0/xe/lib export
LD_LIBRARY_PATH
But if I echo out LD_LIBRARY_PATH in the newer server, it returns nothing. In the older server, it returns what is displayed in the Environment page.
What's going on here? How do I fix this? And is there any other Oracle-related thing I missed?
Thanks to any and all who will help.
I've been incrementally setting up a web server for research and testing purposes. The "server" is running Windows XP and I initially installed Apache Server 2.2 and PHP 5.3. That's been working great for a while. I am now needing to setup MySQL which I downloaded and installed MySQL v5.5. I am able to interact with MySQL via the command-line interface. In the process of setting up phpMyAdmin, I have encountered difficulties getting PHP and Apache to play nice with MySQL. Here's what I've discovered and tried:
In the php.ini file, when I attempt to uncomment either the php_mysql.dll or the php_mysqli.dll extension and restart the Apache server, the server crashes when it starts. The Windows event viewer says Apache failed to start due to "faulting module php5ts.dll".
The extension_dir parameter is set to ".\ext" and the php_mysql.dll and php_mysqli.dll files are in that directory.
I have also tried copying the libmysql.dll file from the lib folder of the MySQL directory to the Windows\System32 directory (with no change in behavior).
I'm at a bit of a loss to figure out what the next step is. Any suggestions?
The extension it's looking for is an extension output by php at compile time based on your configured build options. It is not looking for the header files from mysql itself.
Also, ".\ext" is a relative path that may or may not be valid in your installation. You may need to re-compile php to include mysql and mysqli (you should also compile PDO support) into your php build (Or whatever the windows equivalent of re-compiling is).
Also, you should make extension_dir an absolute path not relative.
I have a Windows Vista PC with IIS7, I have managed to manually install PHP on it.
And managed to load one of my custom extension for PHP, as well as mbstring extension.
But my mysql extension does not load when I check through phpinfo, I checked all the path variable, uncommented requied lines in php.ini file, also verified that the file exists.
My question is, does it require mysql server to be working on the local host for the mysql extension to load? or what could be wrong?
No, but you do need the appropriate MySQL client libraries to be available.
No, php_mysql.dll simply adds the various mysql functions into PHP. How could the .dll know where your server is? Or how you connect to it? Or what if you've got multiple seperate servers?
Until you actually try to connect to the server, the .dll will happily stay idle and not do anything.
If you're not stuck with using IIS, you could investigate installing WAMP - that'll give you MySQL, PHP, and Apache with a nice unified installer, without forcing you to mess around with .dll installation/customization.