This is a very recurring issue with some Oracle's Database users and I have read and tried different approaches withous success.
I am experiencing ORA-03135 error during a SELECT statement. It happens only on specific records of one table. The table has a field defined as varchar(4000) and I discovered that the error occurs when I try to read a record with a big string at the field I told before (about 2000 characters or more).
After some reading I tried to set SQLNET.EXPIRE_TIME, SQLNET.INBOUND_CONNECT_TIMEOUT,
SQLNET.SEND_TIMEOUT and SQLNET.RECV_TIMEOUT without success.
I don't think it is a timeout problem because if I try the same query on a client like Sqlplus it works ad i get the result instantly.
There is no firewall on the network and no alerts/logs are generated on server side when the error occurs. There is also no profile limitation.
I am using an Oracle 11.2 database running on Oracle Linux and PHP OCI8 to retrieve the data.
Is there any other place I could look for?
Thanks in advance!
Ok, just solved it...
I was wrong. It seems the error occurs on strings with some kind of crap at the end of it, not only big ones. Removing the last character solves the problem.
I will do some further investigation and try to discover exactly what is going on.
Edit 1:
100% sure now, the error occurs when the last string is an escape character "\n". Pretty funny, huh?
Related
I want to update customer data which means 10 different columns would be updated in one UPDATE SET WHERE statement but I keep getting a warning in NetBeans that says method length 26 ( allowed 20)
Can anyone tell me what the method length refers to and what another way is to update all those columns in one statement ?
This is an utterly ridiculous hint. You can disable it in
Tools->Options->Editor->Hints->PHP.
It won't disturb you again.
Netbeans is notorious for these informational messages which are really a matter of style preference rather than an actual limitation.
I like to create my SQL code directly using a tool like phpMyAdmin to verify the statement works then port it over to my code.
For what is worth, I suggest you download and install mysql workbench, it will serve as sandbox to test queries before anything else. This always works for me in any development situations
My MySQL db has inserted rows which should not be there, in a particular there is data in a column not generally used. I thought this would make it easy to find which PHP script was inserting the rows but i have searchd all insert querys for the entire site and cannot find which php script is running the insert query.
Its also very hard to replicate as this particular table has many crons updating it.
Can anyone please try point me in the right direction of how I might go about debugging this. Is there a stack track I can use to determine the originating php script. Because it hard to replicate and I've spend two days searching for the code causing the inserts Im open to suggestions.
Im normally quite good at debugging but this bug is like a ghost.
The only thing I can think of, if you have looked at all your code including in all your old cron scripts, is to put an insert trigger on that table, and use it to find out what time of day your extra rows get inserted.
Nasty problem!
This might be a horrible idea depending on your error reporting settings and what type of environment you are debugging in, but if you are in a position to have some errors thrown I'd remove write permissions for the column in question and wait to see what script throws the error. If you are lucky log/report for the error will be written to include a script name and line.
I'm not sure if this is a duplicate of another question, but I have a small PHP file that calls some SQL INSERT and DELETE for an image tagging system. Most of the time both insertions and deletes work, but on some occasions the insertions don't work.
Is there a way to view why the SQL statements failed to execute, something similar to when you use SQL functions in Python or Java, and if it fails, it tells you why (example: duplicate key insertion, unterminated quote etc...)?
There are two things I can think of off the top of my head, and one thing that I stole from amitchhajer:
pg_last_error will tell you the last error in your session. This is awesome for obvious reasons, and you're going to want to log the error to a text file on disk in case the issue is something like the DB going down. If you try to store the error in the DB, you might have some HILARIOUS* hi-jinks in the process of figuring out why.
Log every query to this text file, even the successful ones. Find out if the issue affects identical operations (an issue with your DB or connection, again) or certain queries every time (issue with your app.)
If you have access to the guts of your server (or your shared hosting is good,) enable and examine the database's query log. This won't help if there's a network issue between the app and server, though.
But if I had to guess, I would imagine that when the app fails it's getting weird input. Nine times out of ten the input isn't getting escaped properly or - since you're using PHP, which murders variables as a matter of routine during type conversions - it's being set to FALSE or NULL or something and the system is generating a broken query like INSERT INTO wizards (hats, cloaks, spell_count) VALUES ('Wizard Hat', 'Robes', );
*not actually hilarious
Start monitoring your SQL queries by starting the log. There you can look what all queries are fired and errors if any.
This tutorial to start the logger will help.
Depending on which API your PHP file uses (let's hope it's PDO ;) you could check for errors in your current transaction with s.th. like
$naughtyPdoStatement->execute();
if ($naughtyPdoStatement->errorCode() != '00000')
DebuggerOfChoice::log( implode (' ', $naughtyPdoStatement->errorInfo() );
When using the legacy-APIs there's equivalents like mysql_errno, mysql_error, pg_last_error, etc... which should enable to do the same. DebuggerOfChoice::Log of course can be whatever log function you'd like to utilise
I've been coding with PHP and MySQL for about a year now and have gotten the hang of it pretty well; constructing really complicated queries with joins and calculated fields and all the other joys of MySQL hasn't been a problem for me in months.
BUT there's something syntactically screwy with the following chunk of code that I can't figure out - even though it's impossibly simple, and, even more infuriating, is closely related to other parts of the project that I'm working on (and which works flawlessly).
Here's the problem code I'm trying to run, followed by the bugchecking I've already done to try to isolate the problem.
If anyone has any suggestions, I'd be totally grateful because I'm beginning to lose my mind.
Problem:
I'm really losing my mind over this, so please don't laugh when you see the code:
$query="SELECT count(somefield) FROM db_name WHERE otherfield='".$myvariable."'";
My query finds no results when using a certain variable as part of a field search - even though I know that there are over 900 records in the database that should match.
Bugchecking:
Because I know the value of the variable I'm passing to the query, I've tried hardcoding it into the query and it works fine.
I've run the query in the MySQL console (again, of course, hardcoded instead of with the variable) and it works fine.
To my mind, these two facts eliminate the possibility that there's something syntactically incorrect with the PHP version of the query.
In order to eliminate all possible database connection issues and to make sure the problem isn't related to iterating through the results returned, instead of trying to get the actual results, I've altered my original query to return only the count of the results and have incorporated the standard or die(mysql_error()) statements during the connection sequence. The query is executing, but is finding 0 results, so that eliminates the possibility that it's a connection issue.
I've verified that the field I'm checking is the correct field for the information I'm looking for (like I said, it runs fine if I hardcode the variable into the query... which, of course, will not be an option in the finished code).
I've checked the type of the variable before trying to pass it into the query (figuring that maybe, because it's pulled from a returned xml earlier in the script, that maybe it was showing up as an array or something). It typed as string.
I've verified that the variable is formatted in the way that I expect it to be found in the database; strtoupper, etc.
I've tried using LIKE '%".$myvariable."'"; still no dice.
Anyone have any suggestions for what I can do to figure out what the hell is going wrong? Thanks so much!
It's not a PHP issue so quotes have nothing to do with it.
The query has no error, so you'll need to debug it step by step.
I. SELECT count(*) FROM table_name
II. SELECT count(*) FROM table_name WHERE field='$myvariable'
Where you're dealing with PHP variables in query, echo the query and run it directly in database to omit PHP's side of error.
III. SELECT count(somefield) FROM table_name WHERE field='$myvariable'
Is the $myVariable escaped? If not, escape it using
$escapedVariable=mysql_real_escape_string($myVariable);
and then run
$query="SELECT count(somefield) FROM db_name WHERE otherfield='$escapedVariable'";
Thanks so much to everyone who tried to help, but I figured it out several hours after posting: The first problem was that I forgot to use mysql_real_escape_string($myvariable)... the reasons for how and why I forgot are manifold, but there it is.
So, after plugging that guy back in (which I had ASSUMED had been in this particular module of my code in the first place, but that's where "assuming" gets you, lol), I thought I had the whole thing licked. Three hours later, and still nothing. THEN I realized that it had to be related to XML that was being parsed into the $myvariable... so around and around we went with that one for a few more hours.
FINALLY, I realized that the real culprit was my eyes (which aren't so great).. what looked like a perfectly legit quoted string while reading a debug echo of the query before running turned out to have leading and trailing white space (which, of course, I instantly removed with $myvariable=trim($myvariable, " "), and, that, of course, solved the entire problem...:<
... Yes, I am an idiot, and I'm sorry, but, after working over this UTTERLY INFURIATINGLY stupid line of code for over 48 hours (I'm used to writing things like:
$query="UPDATE db_one.table_one SET item1='".(string)$result_array[$i][1]."', item2='".(string)$result_array[$i][2]."' WHERE thing3=".(string)$result_array[$i][19];
... and other assorted fun nonsense), I had to resort to asking (because I - no pun intended - couldn't "see" the problem... ugh)... SO... I am an idiot, and I'm sorry (but encouraged by the efforts of all of you nice people who tried to help) and am sorry for wasting everyone's time. I need to learn how to handle XML much *more*.
Sorry and thanks again!
I always wrote it like this
$query="SELECT count(somefield) FROM db_name WHERE otherfield='$myvariable' ";
Try removing the double quotes and dot at the variable name
You shouldn't need the parenthesis around the var. Plus look at other changes.
$query="SELECT count(*) FROM table_name WHERE field='$myvariable'";
I am working with a legacy PHP framework and am coming across some strange behavior that I can't track down.
I'm running a query that looks something like this
select * from table where column like '%word-anotherword%'
, which I would like to return records from table where column contains the text "word-anotherword". (column is a longtext field).
When I run this query in phpMyAdmin, I get the expected results. But when I run it from inside our framework, I get no results. I have run it in a separate .php file, using mysql_link, mysql_query to run the query, and that also behaves as expected.
When I echo out the query in the framework directly before it is passed to mysql_query, it is formatted just the same as I expect. I.E. our framework is not escaping it in some unexpected manner.
I am assuming that our framework is overriding some PHP setting somewhere to cause this difference in behavior, but I have had no luck googling for what it might be. I found this article, which seemed to be a good start, but also didn't quite seem to fit what I'm seeing, since I am getting different behaviors on the same MySQL setup.
Any pointers in the right direction would be greatly appreciated!
As a debugging heads-up:
When you echo your query out, you might want to make sure you're actually seeing the data - e.g. if you're echo-ing onto a webpage, make sure you're applying htmlspecialchars() to the string. Otherwise you might not spot some changes.
LIKE is not full text search, that's why question title is wrong and, probably, that article which you found isn't related to your problem.
And about your problem, open your my.cnf and enable queries log:
[mysqld]
#Set General Log
log = "C:/all_queries.log"
Now run your query and look into log.