Very simple-to-explain problem here (at least after struggling with it and simplifying it almost up to the absurd).
I do a connection via the OCI driver inside a file called whatever.Test.php. Just that, make a simple query, and exit. I then call the file from the browser, and the data taken from the database is properly displayed. Next step: I run PHPUnit over the same file, with the following result:
PHP Warning: oci_connect(): ORA-12154: TNS:could not resolve the connect identifier specified in ...
Any ideas?
The final solution was a little bit obvious once I came up with it. Somehow the server could figure out what the server I was trying to connect with was, via the tnsnames.ora file somewhere, I guess. However, since the script execution doesn't trigger all the server processes this information was not reachable any more from there. So what I needed to do is to provide all the data in the oci_connect() $connection_string parameter, using the format [//]host_name[:port][/service_name][:server_type][/instance_name] (check documentation). Previously I was only giving the host_name part.
(Thanks anyway for your reply, user*).
Related
I was given a task of fixing an app after the update.
Presumably, the person who updated it said they updated it to 'Oracle 12c' - whatever that means, thought the path is: 'C:/oracle/product/11.2.0/' which sounds like it's still 11.2.0 or whatever.. not important.
Whenever I'm trying to run oci_connect(); with verified and tested credentials, the error pops:
Warning: oci_connect(): ORA-28040: No matching authentication protocol
I've searched around the internet, found 2 solutions:
download and add 'ojdbc8.jar' to 'C:\oracle\product\11.2.0\client_1\jdbc\lib' (hope the path is correct).
add the lines below to 'sqlnet' which I found in:
'C:\oracle\product...\network\admin\' and
'C:\oracle\ora92\newtork\ADMIN'
**I've changed in both to be
sure**.
The lines:
SQLNET.ALLOWED_LOGON_VERSION=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
Same result, neither worked.
Edit:
I've also noticed, there's no oradmin.exe nor oracle.exe in the bin folder, is this normal?
It sounds like the server is updated and now the client fails to connect. In this case the server needs to configured to allow older client to connect. Add the SQLNET parameters to the server sqlnet.ora file and restart the server.
I'm currently querying a huge Firebird (v2.5) table (with millions of rows) in order to perform some row-level operations. To achieve that, the code is using chunking from Laravel 5.1, somewhat like this:
DB::connection('USER_DB')
->table($table->name)
->chunk(min(5000, floor(65500/count($table->fields))), function($data) {
// running code and saving
});
For some reason, I keep receiving the following error:
SQLSTATE[HY000]: General error: -902 Error reading data from the connection.
I've already tried changing chunk size, and different codes, but the error still appears. Sometime it happens at the beginning of the table, and sometimes after parsing several hundred-thousands or even millions rows. The thing is that I need to parse only the rows in this transaction (so I can't stop and reopen the script).
Tested for memory on the server (running on different place than the database), and it is not using nearly anything of it.
While writing this, I rechecked the Firebird log and found the following entry:
INET/inet_error: read errno = 10054
As far as I could find, this isn't actually a Firebird problem, but a winsock reset error, is that correct? If so, how could I prevent this from happening during the chunk query? And how can I check if that is a problem with windows or the firewall?
Update I
Digging on the firebird2.5.log on the PHP server, found this errors:
INET/inet_error: send errno = 104
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
I have found the root of my problem. The thing is that the server was resetting the connection. In order to avoid that, I added a "heartbeat" query to run every few minutes. With this strategy I was able to prevent the connection from being reset.
I'm trying to use the LOAD DATA LOCAL INFILE command in MySQL, but I keep getting an error in PHP/Joomla stating: The used command is not allowed with this MySQL version
I've spent quite a while Googling around, but the only suggestions I've seen involve adding local-infile = 1 to my my.cnf file (which I've already done, in [client], [mysql], and [mysqld]).
Additionally, if I connect from my Apache server to the MySQL server from the command line (so not using PHP), I can run LOAD DATA LOCAL without issue (so it can't be a permissions thing).
I've also checked php.ini, and sure enough, mysqli.allow_local_infile is set to 'On'.
Am I missing something here?
Do you have to do something special in Joomla to make this work correctly?
I just answered a similar question here, maybe it can help:
After going from MySQL 5.0 to 5.5 I found out that I suddenly have to enable LOCAL INFILE specifically when creating the connection in PHP.
Using mysql:
mysql_connect(server,user,code,false,128); // 128 enables LOCAL INFILE
mysql_select_db(database);
Using mysqli:
$conn = mysqli_init();
mysqli_options($conn, MYSQLI_OPT_LOCAL_INFILE, true);
mysqli_real_connect($conn,server,user,code,database);
I ran into the same problem, in my case it was the Joomla user lacking privileges that root has; giving the full privileges to the J user solved it, but then my component is for distribution so I changed to using standard .sql file and parsing / creating them manually. Hope this helps.
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.
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.
I am testing with MySQL on my home machine using an Apache server under XAMPP with the MySQL settings: Server: localhost via TCP/IP, version 5.5.16.
I have a query: SELECT * FROM project WHERE refno = $refno;
This works perfectly on my test machine. When I try the same thing on my ISP server, which has the following settings: Server: localhost via UNIX socket, version 5.0.92
I get the message:
"supplied argument is not a valid MySQL result resource"
Is the problem the difference in the settings? Is there anything I can do to get it working?
I would recommend you first make absolutely sure you have a valid database connection. Look for mysql_connect in your script, and make sure it is being passed the proper parameters. Look for the code examples on the man page to see how to add die() calls to catch any problems. Using die() is not a practice I would recommend on production code, though. You would usually want to catch and log errors, instead of having the script die.
Once you have made sure your connection returns a ressource, if it still chokes on you make sure you are sending the proper parameter (database name) to mysql_select_db.
Once these forementioned two functions play nice, your query should execute no problem.
Hope that helps, good-luck.