large sql query causes error when line breaks removed - mysql

I have a very large and complex MySQL query that gets run from a Node.JS process, but I am getting a strange error.
The query is about 150 lines of SQL code, so I'm not going to include it, but I know it's good. It is written in the JS source code as a variable with \ at the end of the each line to continue the string. If I copy the SQL from the source and remove the \s it runs perfectly. However, when I run it through the app, I get the dreaded:
MySQL: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
'' anywhere in the huge single line that is my query - thanks MySQL.
When I get the app to output the SQL to the screen and I copy and paste that, I get the same error in MySQL. I decided to run the 2 queries (source when \ removed and the output) through diff, and the only difference is the line breaks - the source has line breaks, and the output doesn't. I should also note, that simpler queries in this app do work, so there's something in this query causing this.
What possible change could be happening to the MySQL query when the line breaks are removed? Is there some limit of lines or spaces that I am unaware of? My understanding is that MySQL ignores all line breaks and whitespace. Is this not true? Could someone point me in the right direction to trouble shoot this?
There were some comments that I removed, there were some blank lines that I removed, I converted the tabs to spaces.. I'm out of ideas.
Thanks,
whiteatom

Missed a comment in the query. I was using the -- MySQL comment syntax which comments to the end of the line. When the line breaks are removed - the query was terminated at that comment.
Thanks for looking; hope this helps someone else.

Related

MySQL find and replace not working as expected (serialized data)

Im trying to create a MySQL search and replace script for my wp_postmeta db table.
I need to search this fields that are similar to this.
a:2:{i:0;a:3:{s:4:"name";s:15:"Personalisation";s:4:"type";s:7:"heading";s:11:"description";s:0:"";}i:1;a:13:{s:4:"name";s:8:"Initials";s:12:"title_format";s:5:"label";s:4:"type";s:11:"custom_text";s:17:"restrictions_type";s:8:"any_text";s:11:"description";s:0:"";s:18:"description_enable";i:0;s:8:"required";i:1;s:3:"min";s:1:"1";s:3:"max";s:1:"4";s:12:"restrictions";i:1;s:5:"price";s:1:"3";s:10:"price_type";s:14:"quantity_based";s:12:"adjust_price";i:1;}}
and replace the "required";i:1; with "required";i:0;
Im using phpmyadmin to create and run the script but so far I cannot get what I have written to run with the semicolons in there.
This is what ive come up with so far;
UPDATE wp_postmeta
SET meta_value = replace(meta_value, '"required";i:1;', '"required";i:0;')
WHERE meta_key = '_product_addons';
and get the error (removing the semicolons fixes this but then doesn't match anything):
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''"required")' at line 1
I've tried using \ to escape them and this doesn't work, this is about as far as my knowledge goes with MySQL so hoping someone can help?
Thanks
OK so I've found out that this actually works fine but won't work when using the Simulate option, can anyone explain why this is?

Simple SQL update query not working

I need to run this query but I get an error:
UPDATE wp_usermeta
SET meta_value = "a:1:{s:16:\"client_special\";b:1;}"
WHERE user_id = "1009";
But I get this error:
You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'UPDATE wp_usermeta
SET meta_value = "a:1:{s:16:\"cliente_especial\";b:1;}" W' at line 1
It is ok for me, I escaped the " with \ character.
As you discovered, and as my comment alluded, non-printing or hidden characters in your SQL statement can lead to unexpected syntax errors.
When confronted with what appears to be ludicrous messages, I find carefully retyping the statement into a different program helps decide whether it is a hidden character issue or a legitimate syntax issue.
It is the act of careful retyping that sanitizes the statement and rules out the non-printing characters. More than once I've done this and I imagine I will continue to do this for the rest of my career!

MySQL label statement not recognized in PROCEDURE declaration

I'm trying to use a label statement in the MySQL exactly as described in doc.
I permanently get an error on the colon behind label :
What is wrong?
I already tried XAMPP with the MariaDB as well as WAMP with the MySQL. I try as simple procedure as possible. From SQL tab in phpMyAdmin as well as from file script in Import. All the same : Unexpected character near ":".
I found issue that the TAB in the procedure definition may cause problem. I have not there any TAB. I tried loop and LOOP, begin vs. BEGIN.... still same... Please help.
You have END LOOP try changing it to END LOOP loop1; see MySQL document.
Your code is confirmed to work fine in MySQL 5.6 -- here's a SQL Fiddle: http://sqlfiddle.com/#!9/c00911/1. I also suspect the phpMyAdmin client.
Try putting the label on its own line, or taking the numeric out of the label (take the word loop out of it, too -- maybe it's parsing it funny). Call it var_counter maybe.

You have an error in your SQL syntax near '<!

Trying to relocate a Wordpress DB and are running in to this issue all the time.
Been trying all the normal stuff to get it working optimizing, repairing etc and also try to import it with several tools (Sequel pro etc ) and over ssh.
Have the issue occurring over several tables and can see that other's have had the same. Because i can't import any copy i would need some expertise advice how to solve this either in phpmyadmin or ssh.
Error message is
#mysql -u -p db < /tmp/file.sql
> ERROR 1064 (42000) at line 109088: You have an error in your SQL
> syntax; check the manual that corresponds to your MySQL server version
> for the right syntax to use near '<!
> <div class="error"><h1>Error</h1> <p><strong>SQL query:</strong> <a href=' at line 1
Don't really know how to approach it because i find this all over the DB
like
<image:caption><![CDATA
Any advice?
Since "all the normal stuff" isn't working...
I'm going to take a guess, you are a running something to "copy" the contents of a database table, or you're doing some sort of "dump" or "export" that creates SQL statements.
And the SQL statements that are running against the target are throwing an error.
We can't tell (from where we're sitting and what we're seeing) what it is you are actually doing, we're just guessing.
The two most likely possibilities:
Whatever tool you are using isn't expecting that the column values being copied might contain values that need to be "escaped" if that value is incorporated in the text of a SQL statement. For example, suppose I have a column value like this:
I'd like a pony
and If I grab that value and I naively stick that into the text of a SQL statement, without regard for any characters it might contain, e.g.
INSERT INTO foo (bar) VALUES ('I'd like a pony');
If I try to execute that statement, MySQL is going to throw a syntax error. MySQL is going to see a string literal with a value of 'I' (the single quote that is part of the string is now being seen as the end of the string literal. MySQL is going to flag a syntax error on what follows d like a pony.
When we take a value and build a SQL statement from it, we have to properly escape the values. In this example, the insert statement to reproduce that string value could look like this:
INSERT INTO foo (bar) VALUES ('I''d like a pony');
^^
If this is what's happening, you can be thankful that the column values didn't include something more nefarious...
Robert'); DROP TABLE students; --
But without seeing the actual SQL statement that is being executed, this is just a guess at what is causing the issue.
Is there some kind of guide or some instructions that you are following to "relocate a Wordpress DB" which documents "all the normal stuff" that you are doing?
FOLLOWUP
Question was edited to add this information:
mysql -u -p db < /tmp/file.sql
What's important here is the contents of file.sql.
The problem is most likely in the part of "all the normal stuff" is producing that file. That part is effectively broken because it's not expecting that an extracted column value can contain a single quote character, and is not properly escaping the value before it's incorporated into the text of a SQL INSERT statement.

MySQL adding extra backslashes?

##SESSION.sql_mode;
##GLOBAL.sql_mode;
both come up blank, the my.cnf shows no "NO_BACKSLASH_ESCAPE" flag and this is a section of a query which runs on my local server but not on my main.
UPDATE `table`
SET `data` = "[{\"_talent\'s\"etc"
Now I know I can use "[{""_talents""etc" but I'd rather not since it is much easier for me to keep to my current escaping security methods which have always worked before.
The charset is UTF-8 of the table I'm updating. The strangest thing is that it works on insert but not update!
This one really has me scratching. Any ideas?
Cheers
edit:
I've found out that the server is trying to interpret the query like so:
Failed to execute SQL : SQL UPDATE `build` SET `data` = "[{\"_talent\'s" WHERE `build_id` = 1 AND `userId` = 1128; failed : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UPDATE `build` SET `data` = "[{\\"_talent\\'s" WHERE `build_id` = 1 AND `userId`' at line 1
Yet surely it should be the same, why is the SQL engine escaping my escapes!? (if I leave out the escapes the query still fails)
You can try this -
UPDATE 'table'
SET 'data' = '[{"_talents"etc'
Is this relevant?
MySQL / PHP problem with " and '
Which implys you may have magic Quotes enabled somewhere to add extra backslashes (which may explain why you get odd behaviout on your server but not your local machine)?
The different behaviour on both platforms implies some configuration issue on the server to me (you sure they are the same version?) I'm reaching a bit here though.
I found out it seems to have been my version of webmin adding it in on the console... d'oh
When I ran the query from PHP it went through perfectly.
Many thanks though.