I have the following mysql code which I run in a shell script:
mysql -u "$DB_USER" -p"$DB_PASSWD" "$DB_SOURCE" << MYSQLEOF
DELETE FROM list_subscriber_events WHERE subscriberid IN
(SELECT subscriberid FROM
(SELECT subscriberid FROM `list_subscriber_events` WHERE subscriberid NOT IN
(SELECT subscriberid FROM list_subscribers)) AS c);
MYSQLEOF
When running the delete query from the command line in mysql I have no problems - it runs ok.
However when running it in the bash script I get the following error:
ERROR 1064 (42000) at line 4: 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 'WHERE subscriberid NOT IN
(SELECT subscriberid FROM list_subscribers)) AS c)' at line 3
ssh exited with exit code 1
I've spent hours trying all sorts of variations - I can't seem to resolve it. Any help would be appreciated - I'm probably missing something obvious.
Try removing the backtick characters
FROM `list_subscriber_events` WHERE
^ ^
In the context of a shell command line, those backticks indicate something that needs to be run, and the return from that is substituted.
I suspect that the shell is interpreting those backticks, and attempting to execute list_subscriber_events, which is likely returning an error. The result is that this gets replaced with an empty string... the resulting statement is
... FROM WHERE ...
If you have to include backticks, likely preceding the backtick with a backslash character will escape it.
FOLLOWUP
On a totally different note, it seems like you have more inline views that are necessary. And there's a potential "gotcha" with the NOT IN, if the subquery returns a NULL value. (Maybe you have a guarantee that subscriberid is NOT NULL in list_subscribers. Or, maybe you do want the behavior we get when that subquery returns a NULL value.)
Seems like a much simpler query, using an anti-join pattern would accomplish the result you seem to be after... to remove the rows from list_subscriber_events where the subscriberid value does not appear in list_subscribers
DELETE e.*
FROM list_subscriber_events e
LEFT
JOIN list_subscribers l
ON l.subscriberid = d.subscriberid
WHERE l.subscriberid IS NULL
Related
What's the problem with this query?
It's only a slight modification from the SQL for mere mortals book...
Select r.RecipeTitle,
from (Select RecipeClassID
from recipe_classes as RC
where RC.RecipeClassDescription like "Main%"
or RC.RecipeClassDescription="Dessert") as rcfiltered
inner join recipes as r
on rcfiltered.RecipeClassID = r.RecipeClassID;
Remove the comma:
Select recipes.RecipeTitle,
from ...
There must be no comma following the last expression in the select-list.
WRONG:
SELECT A, B, C, FROM ...
RIGHT:
SELECT A, B, C FROM ...
With the extra comma, the query produces this error in MySQL:
ERROR 1064 (42000): 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 'from (Select RecipeClassID
from recipe_classes as RC
where RC.Recipe' at line 2
Here's a tip on how to read syntax error messages: It tells you exactly where the parser got confused: "near 'from ..." This probably means something you wrote in the query immediately prior to that position was wrong. Knowing this helps to narrow down the cause of the syntax error.
If the error says, "near ''" then it means it got to the end of the query and then got confused. Maybe you opened a parenthesis but forgot to close it for example.
That's the first problem that jumps out at me. I don't know the original query you were modifying, so I don't know how you changed it. I don't know if the query does what you intend it to do, but aside from the comma issue it looks like the syntax is valid.
When issuing a command to MySQL, I'm getting error #1064 "syntax error".
What does it mean?
How can I fix it?
TL;DR
Error #1064 means that MySQL can't understand your command. To fix it:
Read the error message. It tells you exactly where in your command MySQL got confused.
Examine your command. If you use a programming language to create your command, use echo, console.log(), or its equivalent to show the entire command so you can see it.
Check the manual. By comparing against what MySQL expected at that point, the problem is often obvious.
Check for reserved words. If the error occurred on an object identifier, check that it isn't a reserved word (and, if it is, ensure that it's properly quoted).
Aaaagh!! What does #1064 mean?
Error messages may look like gobbledygook, but they're (often) incredibly informative and provide sufficient detail to pinpoint what went wrong. By understanding exactly what MySQL is telling you, you can arm yourself to fix any problem of this sort in the future.
As in many programs, MySQL errors are coded according to the type of problem that occurred. Error #1064 is a syntax error.
What is this "syntax" of which you speak? Is it witchcraft?
Whilst "syntax" is a word that many programmers only encounter in the context of computers, it is in fact borrowed from wider linguistics. It refers to sentence structure: i.e. the rules of grammar; or, in other words, the rules that define what constitutes a valid sentence within the language.
For example, the following English sentence contains a syntax error (because the indefinite article "a" must always precede a noun):
This sentence contains syntax error a.
What does that have to do with MySQL?
Whenever one issues a command to a computer, one of the very first things that it must do is "parse" that command in order to make sense of it. A "syntax error" means that the parser is unable to understand what is being asked because it does not constitute a valid command within the language: in other words, the command violates the grammar of the programming language.
It's important to note that the computer must understand the command before it can do anything with it. Because there is a syntax error, MySQL has no idea what one is after and therefore gives up before it even looks at the database and therefore the schema or table contents are not relevant.
How do I fix it?
Obviously, one needs to determine how it is that the command violates MySQL's grammar. This may sound pretty impenetrable, but MySQL is trying really hard to help us here. All we need to do is…
Read the message!
MySQL not only tells us exactly where the parser encountered the syntax error, but also makes a suggestion for fixing it. For example, consider the following SQL command:
UPDATE my_table WHERE id=101 SET name='foo'
That command yields the following error message:
ERROR 1064 (42000): 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 'WHERE id=101 SET name='foo'' at line 1
MySQL is telling us that everything seemed fine up to the word WHERE, but then a problem was encountered. In other words, it wasn't expecting to encounter WHERE at that point.
Messages that say ...near '' at line... simply mean that the end of command was encountered unexpectedly: that is, something else should appear before the command ends.
Examine the actual text of your command!
Programmers often create SQL commands using a programming language. For example a php program might have a (wrong) line like this:
$result = $mysqli->query("UPDATE " . $tablename ."SET name='foo' WHERE id=101");
If you write this this in two lines
$query = "UPDATE " . $tablename ."SET name='foo' WHERE id=101"
$result = $mysqli->query($query);
then you can add echo $query; or var_dump($query) to see that the query actually says
UPDATE userSET name='foo' WHERE id=101
Often you'll see your error immediately and be able to fix it.
Obey orders!
MySQL is also recommending that we "check the manual that corresponds to our MySQL version for the right syntax to use". Let's do that.
I'm using MySQL v5.6, so I'll turn to that version's manual entry for an UPDATE command. The very first thing on the page is the command's grammar (this is true for every command):
UPDATE [LOW_PRIORITY] [IGNORE] table_reference
SET col_name1={expr1|DEFAULT} [, col_name2={expr2|DEFAULT}] ...
[WHERE where_condition]
[ORDER BY ...]
[LIMIT row_count]
The manual explains how to interpret this syntax under Typographical and Syntax Conventions, but for our purposes it's enough to recognise that: clauses contained within square brackets [ and ] are optional; vertical bars | indicate alternatives; and ellipses ... denote either an omission for brevity, or that the preceding clause may be repeated.
We already know that the parser believed everything in our command was okay prior to the WHERE keyword, or in other words up to and including the table reference. Looking at the grammar, we see that table_reference must be followed by the SET keyword: whereas in our command it was actually followed by the WHERE keyword. This explains why the parser reports that a problem was encountered at that point.
A note of reservation
Of course, this was a simple example. However, by following the two steps outlined above (i.e. observing exactly where in the command the parser found the grammar to be violated and comparing against the manual's description of what was expected at that point), virtually every syntax error can be readily identified.
I say "virtually all", because there's a small class of problems that aren't quite so easy to spot—and that is where the parser believes that the language element encountered means one thing whereas you intend it to mean another. Take the following example:
UPDATE my_table SET where='foo'
Again, the parser does not expect to encounter WHERE at this point and so will raise a similar syntax error—but you hadn't intended for that where to be an SQL keyword: you had intended for it to identify a column for updating! However, as documented under Schema Object Names:
If an identifier contains special characters or is a reserved word, you must quote it whenever you refer to it. (Exception: A reserved word that follows a period in a qualified name must be an identifier, so it need not be quoted.) Reserved words are listed at Section 9.3, “Keywords and Reserved Words”.
[ deletia ]
The identifier quote character is the backtick (“`”):
mysql> SELECT * FROM `select` WHERE `select`.id > 100;
If the ANSI_QUOTES SQL mode is enabled, it is also permissible to quote identifiers within double quotation marks:
mysql> CREATE TABLE "test" (col INT);
ERROR 1064: You have an error in your SQL syntax...
mysql> SET sql_mode='ANSI_QUOTES';
mysql> CREATE TABLE "test" (col INT);
Query OK, 0 rows affected (0.00 sec)
It is late but will help others and ofcourse will save time :)
My query was working in MySQL 5.7 in local system but on live we have version MySQL 8 and query stop working.
Query:
SELECT t.*
FROM groups t
ORDER BY t.id DESC
LIMIT 10 OFFSET 0
Output in MySQL 8:
Error in query (1064): Syntax error near 'groups t ORDER BY t.id DESC'
at line ...
I came to know groups is reserved word so I have to wrap groups with `` quotes or change the table name to solve this issue.
For my case, I was trying to execute procedure code in MySQL, and due to some issue with server in which Server can't figure out where to end the statement I was getting Error Code 1064. So I wrapped the procedure with custom DELIMITER and it worked fine.
For example, Before it was:
DROP PROCEDURE IF EXISTS getStats;
CREATE PROCEDURE `getStats` (param_id INT, param_offset INT, param_startDate datetime, param_endDate datetime)
BEGIN
/*Procedure Code Here*/
END;
After putting DELIMITER it was like this:
DROP PROCEDURE IF EXISTS getStats;
DELIMITER $$
CREATE PROCEDURE `getStats` (param_id INT, param_offset INT, param_startDate datetime, param_endDate datetime)
BEGIN
/*Procedure Code Here*/
END;
$$
DELIMITER ;
When issuing a command to MySQL, I'm getting error #1064 "syntax error".
What does it mean?
How can I fix it?
TL;DR
Error #1064 means that MySQL can't understand your command. To fix it:
Read the error message. It tells you exactly where in your command MySQL got confused.
Examine your command. If you use a programming language to create your command, use echo, console.log(), or its equivalent to show the entire command so you can see it.
Check the manual. By comparing against what MySQL expected at that point, the problem is often obvious.
Check for reserved words. If the error occurred on an object identifier, check that it isn't a reserved word (and, if it is, ensure that it's properly quoted).
Aaaagh!! What does #1064 mean?
Error messages may look like gobbledygook, but they're (often) incredibly informative and provide sufficient detail to pinpoint what went wrong. By understanding exactly what MySQL is telling you, you can arm yourself to fix any problem of this sort in the future.
As in many programs, MySQL errors are coded according to the type of problem that occurred. Error #1064 is a syntax error.
What is this "syntax" of which you speak? Is it witchcraft?
Whilst "syntax" is a word that many programmers only encounter in the context of computers, it is in fact borrowed from wider linguistics. It refers to sentence structure: i.e. the rules of grammar; or, in other words, the rules that define what constitutes a valid sentence within the language.
For example, the following English sentence contains a syntax error (because the indefinite article "a" must always precede a noun):
This sentence contains syntax error a.
What does that have to do with MySQL?
Whenever one issues a command to a computer, one of the very first things that it must do is "parse" that command in order to make sense of it. A "syntax error" means that the parser is unable to understand what is being asked because it does not constitute a valid command within the language: in other words, the command violates the grammar of the programming language.
It's important to note that the computer must understand the command before it can do anything with it. Because there is a syntax error, MySQL has no idea what one is after and therefore gives up before it even looks at the database and therefore the schema or table contents are not relevant.
How do I fix it?
Obviously, one needs to determine how it is that the command violates MySQL's grammar. This may sound pretty impenetrable, but MySQL is trying really hard to help us here. All we need to do is…
Read the message!
MySQL not only tells us exactly where the parser encountered the syntax error, but also makes a suggestion for fixing it. For example, consider the following SQL command:
UPDATE my_table WHERE id=101 SET name='foo'
That command yields the following error message:
ERROR 1064 (42000): 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 'WHERE id=101 SET name='foo'' at line 1
MySQL is telling us that everything seemed fine up to the word WHERE, but then a problem was encountered. In other words, it wasn't expecting to encounter WHERE at that point.
Messages that say ...near '' at line... simply mean that the end of command was encountered unexpectedly: that is, something else should appear before the command ends.
Examine the actual text of your command!
Programmers often create SQL commands using a programming language. For example a php program might have a (wrong) line like this:
$result = $mysqli->query("UPDATE " . $tablename ."SET name='foo' WHERE id=101");
If you write this this in two lines
$query = "UPDATE " . $tablename ."SET name='foo' WHERE id=101"
$result = $mysqli->query($query);
then you can add echo $query; or var_dump($query) to see that the query actually says
UPDATE userSET name='foo' WHERE id=101
Often you'll see your error immediately and be able to fix it.
Obey orders!
MySQL is also recommending that we "check the manual that corresponds to our MySQL version for the right syntax to use". Let's do that.
I'm using MySQL v5.6, so I'll turn to that version's manual entry for an UPDATE command. The very first thing on the page is the command's grammar (this is true for every command):
UPDATE [LOW_PRIORITY] [IGNORE] table_reference
SET col_name1={expr1|DEFAULT} [, col_name2={expr2|DEFAULT}] ...
[WHERE where_condition]
[ORDER BY ...]
[LIMIT row_count]
The manual explains how to interpret this syntax under Typographical and Syntax Conventions, but for our purposes it's enough to recognise that: clauses contained within square brackets [ and ] are optional; vertical bars | indicate alternatives; and ellipses ... denote either an omission for brevity, or that the preceding clause may be repeated.
We already know that the parser believed everything in our command was okay prior to the WHERE keyword, or in other words up to and including the table reference. Looking at the grammar, we see that table_reference must be followed by the SET keyword: whereas in our command it was actually followed by the WHERE keyword. This explains why the parser reports that a problem was encountered at that point.
A note of reservation
Of course, this was a simple example. However, by following the two steps outlined above (i.e. observing exactly where in the command the parser found the grammar to be violated and comparing against the manual's description of what was expected at that point), virtually every syntax error can be readily identified.
I say "virtually all", because there's a small class of problems that aren't quite so easy to spot—and that is where the parser believes that the language element encountered means one thing whereas you intend it to mean another. Take the following example:
UPDATE my_table SET where='foo'
Again, the parser does not expect to encounter WHERE at this point and so will raise a similar syntax error—but you hadn't intended for that where to be an SQL keyword: you had intended for it to identify a column for updating! However, as documented under Schema Object Names:
If an identifier contains special characters or is a reserved word, you must quote it whenever you refer to it. (Exception: A reserved word that follows a period in a qualified name must be an identifier, so it need not be quoted.) Reserved words are listed at Section 9.3, “Keywords and Reserved Words”.
[ deletia ]
The identifier quote character is the backtick (“`”):
mysql> SELECT * FROM `select` WHERE `select`.id > 100;
If the ANSI_QUOTES SQL mode is enabled, it is also permissible to quote identifiers within double quotation marks:
mysql> CREATE TABLE "test" (col INT);
ERROR 1064: You have an error in your SQL syntax...
mysql> SET sql_mode='ANSI_QUOTES';
mysql> CREATE TABLE "test" (col INT);
Query OK, 0 rows affected (0.00 sec)
It is late but will help others and ofcourse will save time :)
My query was working in MySQL 5.7 in local system but on live we have version MySQL 8 and query stop working.
Query:
SELECT t.*
FROM groups t
ORDER BY t.id DESC
LIMIT 10 OFFSET 0
Output in MySQL 8:
Error in query (1064): Syntax error near 'groups t ORDER BY t.id DESC'
at line ...
I came to know groups is reserved word so I have to wrap groups with `` quotes or change the table name to solve this issue.
For my case, I was trying to execute procedure code in MySQL, and due to some issue with server in which Server can't figure out where to end the statement I was getting Error Code 1064. So I wrapped the procedure with custom DELIMITER and it worked fine.
For example, Before it was:
DROP PROCEDURE IF EXISTS getStats;
CREATE PROCEDURE `getStats` (param_id INT, param_offset INT, param_startDate datetime, param_endDate datetime)
BEGIN
/*Procedure Code Here*/
END;
After putting DELIMITER it was like this:
DROP PROCEDURE IF EXISTS getStats;
DELIMITER $$
CREATE PROCEDURE `getStats` (param_id INT, param_offset INT, param_startDate datetime, param_endDate datetime)
BEGIN
/*Procedure Code Here*/
END;
$$
DELIMITER ;
Someone gave me this query to delete community from a database on my server using phpMyAdmin, it worked when he use it so I asked him to send it to me, but I get a error
MySQL said:
Documentation
#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 '"SELECT * FROM `connections` WHERE 1" :
delete from connections where communit' at line 1
I did a search on the error but could not figure it out.
"SELECT * FROM `connections` WHERE 1" :
delete from connections where community="XYZ"
You should separate your queries with ; and not :
The error you are receiving as you've shown it is because this line is incorrect:
SELECT * FROM `connections` WHERE 1"
First because it's ending in an unnecessary double quotation mark. MySQL does not use double quotes but single quotes, and even still the other single quote is not there to match it.
The single quotes are also a problem for community="XYZ", this should read: community = 'XYZ'
Secondly, you don't have a condition for your where statement, you must be missing something like:
WHERE columnName = 1;
If you were trying to select everything from connections, you can just remove that where clause all together.
EDIT
In addition, MySQL queries are separated by a semi-colon, not a colon, so MySQL will not realize you are trying two different queries.
I have a query:
select first_name from users where user_id=1
UNION
SELECT IF(SUBSTRING user(),1,4) = 'root',SLEEP(5),1);
Whenever I run it I get the following error:
ERROR 1064 (42000): 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 'user(),1,4) = 'root',SLEEP(5),1)' at line 1
My purpose is to test whether the user is root.
SUBSTRING user(),1,4) means: starting from position 1, get four characters (so basically root) .If the database user is root then pause for 5 seconds.
But SLEEP(5),1) what does it mean apart from instructing to pause for the specified 5 sec?
Thanks a lot
The right sintax is:
IF(SUBSTRING(user(),1,4) = 'root',SLEEP(5),1)
you are just missing a (. Maybe you can also use this:
IF(user() like "root%", SLEEP(5), 1).
Sleep(n) just pauses the execution of the query for n seconds. I don't find it really useful... but it's possible to do.