oci_connect fails from command line but works in browser

Question

I wrote a PHP script to run as a cron job and it wasn't running. The script worked fine in the browser, but I discovered when I ran it from the command line that I got this error:

Warning: oci_connect(): ORA-12154: TNS:could not resolve the connect identifier specified in /usr/apps/webdata/cron/PropogateDB.php on line 190

The line in question is:

$conn_NRB = oci_connect($user, $pass, "nrb.njbbnrbpd1");

As I said this script works fine in the browser.

I did some digging around and found the configuration settings for the database. I then tried this:

$conn_NRB = oci_connect($user, $pass, "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=nrb)))");

With this code both the command line and the browser give me this error:

Warning: oci_connect() [function.oci-connect]: ORA-01017: invalid username/password; logon denied in /usr/apps/webdata/cron/PropogateDB.php on line 191

As far as I know there are no other usernames and passwords that I can use. (I'm trying to verify that now.)

I searched around on this site and discovered someone else with a similar problem, although his problem was reversed, and his cause was that the command line and the browser pointed to two different php.ini files. I just confirmed that both the browser and the command line invoke the same php.ini file. They both point to:

Configuration File (php.ini) Path => /usr/local/php/lib

Is there any other reason why a script would work in the browser but fail in the command line? I'm relatively new to Oracle SQL and I don't have direct access to the database so I'm not sure where to go from here.

Thanks.

Answer 1

The 'EasyConnect' string

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=nrb)))

refers to localhost. 'In the browser' likely means: on the server (where the PHP script executes).

Unless you run the test on the command - line of the same server , you should change the connect string to refer to the Database server (which might be simply the host name of your web-server).

Beware of firewall restrictions that may come in the way. Prefer to use your company's tnsnames.ora to resolve database instances identifiers to their connect strings, if possible.