Ошибка error 1064 42000 you have an error in your sql syntax

при выдаче команды MySQL я получаю ошибку #1064 «синтаксическая ошибка».

Как я могу это исправить?

6 ответов

TL; DR

• прочитайте сообщение об ошибке. он говорит вам именно там, где в вашей команде MySQL запутался.

• проверьте в руководстве пользователя. по сравнению с тем, что MySQL ожидается, что в этот момент, проблема часто очевидное.

• Проверьте зарезервированные слова. если ошибка произошла с идентификатором объекта, проверьте, что это не зарезервированное слово (и, если это так, убедитесь, что оно правильно указано).

проверил!! Что делает #1064 mean?

ошибка посмотреть как gobbledygook, но они (часто) невероятно информативны и предоставляют достаточные детали, чтобы точно определить, что пошло не так. Понимая точно, что MySQL говорит вам, вы можете вооружиться, чтобы исправить любую проблему такого рода в будущем.

как и во многих программах, ошибки MySQL кодируются в соответствии с тип проблемы, которая произошла. ошибка #1064 ошибка синтаксиса.

что это «синтаксис», о котором вы говорите? Это колдовство?

в то время как «синтаксис» — это слово, которое многие программисты сталкиваются в контексте компьютеры, по сути, заимствованы из более широкой лингвистики. Это относится к структуре предложения, т. е. правила грамматики; или, другими словами, правила, определяющие, что составляет действующий приговор в рамках языка.

например, следующее английское предложение содержит синтаксическую ошибку (поскольку неопределенная статья » a » всегда должна предшествовать существительному):

это предложение содержит синтаксическую ошибку a.

какое это имеет отношение к MySQL?

всякий раз, когда кто-то выдает команду компьютеру, одна из самых первых вещей, которые он должен сделать, это «разобрать» эту команду, чтобы понять ее. «Синтаксическая ошибка» означает, что синтаксический анализатор не может понять, что спрашивается, потому что он не представляет собой допустимую команду в языке: другими словами, команда нарушает грамматику программирования язык.

важно отметить, что компьютер должен понять команду, прежде чем он сможет что-либо с ней сделать. Поскольку есть синтаксическая ошибка, MySQL понятия не имеет, что нужно, и поэтому отказывается прежде чем он даже выглядит по базе данных и поэтому схема или содержимое таблицы не имеют значения.

как это исправить?

очевидно, нужно определить, как это происходит, что команда нарушает грамматику MySQL. Это может показаться довольно непроницаемым, но MySQL очень старается помочь нам здесь. Все, что нам нужно сделать, это. —27—>

читать сообщения!

MySQL не только говорит нам ровно где синтаксический анализатор обнаружил ошибку синтаксиса, но также делает предложение для ее исправление. Например, рассмотрим следующую команду SQL:

эта команда выдает следующую ошибку сообщение:

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 SET name=’foo» at line 1

MySQL говорит нам, что все казалось прекрасным до слова WHERE , но затем возникла проблема. Другими словами, он не ожидал встретить WHERE в этой точке.

сообщения, которые говорят . near » at line. просто означает, что конец команды был обнаружен неожиданно: то есть что-то еще должно появиться до завершения команды.

подчиняться приказы!

MySQL также рекомендует, чтобы мы»проверьте руководство, которое соответствует нашей версии MySQL для правильного синтаксиса, чтобы использовать«. Давайте сделаем это.

я используете MySQL версии 5.6, так что я буду говорить эта версия ручной ввод для UPDATE команда. Самое первое на странице-это грамматика команды (это верно для каждой команды):

в руководстве объясняется, как интерпретировать этот синтаксис в типографские и синтаксические соглашения, но для наших целей достаточно признать, что: предложения, содержащиеся в квадратных скобках [ и ] являются необязательными; вертикальные полосы | укажите альтернативы; и эллипсы . обозначьте либо опущение для краткости, либо то, что предыдущее предложение может быть повторено.

мы уже знаем, что парсер верил, что все в нашей команде было в порядке до WHERE ключевое слово, или другими словами До и включая ссылку на таблицу. Глядя на грамматику, мы видим, что table_reference должен следовать SET ключевое слово: тогда как в нашей команде за ним фактически следовали WHERE ключевое слово. Это объясняет, почему анализатор сообщает, что в этот момент возникла проблема.

примечание о бронировании

конечно, это был простой пример. Однако, следуя двум шагам, изложенным выше (т. е. наблюдая точно, где в команде парсер обнаружил, что грамматика была нарушена и сравнивается с описанием руководства что ожидалось в тот момент), практически каждая синтаксическая ошибка может быть легко идентифицирована.

я говорю «практически все», потому что есть небольшой класс проблем, которые не так легко обнаружить-и именно там парсер считает, что элемент языка, с которым столкнулся, означает одно, тогда как вы намереваетесь это означать другое. Возьмем следующий пример:

опять же, парсер не ожидает столкнуться WHERE в этот момент и так возникнет аналогичная синтаксическая ошибка-но вы не предназначались для этого where быть ключевым словом SQL: вы намеревались определить столбец для обновления! Однако, как указано в разделе Имена Объектов Схемы:

если идентификатор содержит специальные символы или является зарезервированным словом, вы должны цитировать всякий раз, когда вы обращаетесь к нему. (Исключение: зарезервированное слово, которое следует за точкой в полном имени, должно быть идентификатором, поэтому его не нужно цитировать.) Зарезервированные слова перечислены в раздел 9.3, «ключевые слова и зарезервированные слова».

символ цитаты идентификатора-это backtick (» ` «):

если ANSI_QUOTES включен режим SQL, также допустимо указывать идентификаторы в двойном предложении Маркс:

Если вы получаете ошибку с клиентом SQuirreL при запуске SQL rxpression с точкой с запятой, как процедура CREATE, то вам нужен плагин MySQL. Вы можете выбрать его при установке. По умолчанию он не выбран.

для моего случая я пытался выполнить код процедуры в MySQL, и из-за какой-то проблемы с сервером, на котором сервер не может понять, где закончить оператор, я получал код ошибки 1064. Поэтому я обернул процедуру пользовательским разделителем, и она работала нормально.

например, раньше было:

после установки разделителя это было так:

вы также получаете эту ошибку при попытке вставить JSON или другие данные со специальными символами, без необходимых кавычек, например:

различные причины.. скажем, например, если мы объявляем любую переменную, то она должна быть перед любым другим типом операторов. или нам нужно поставить блок BEGIN перед этим.

дает ошибку, поэтому нам нужно сделать это

это может быть потому, что ваша строка или вставленные данные содержат одиночная кавычка ‘ вы можете попробовать

функция для выхода из строки при вставке данных (insert query) в базу данных.

MySQL error 1064

Статья ориентирована на новичков. В ней объясняется, что означает ошибка сервера MySQL №1064, рассматриваются типичные ситуации и причины возникновения этой ошибки, а также даются рекомендации по исправлению.

Рассмотрим простейший пример.

Сервер MySQL сообщает, что в первой строке нашего SQL запроса имеется синтаксическая ошибка, и в одинарных кавычках цитирует часть запроса с того места где начинается ошибка. Это очень полезное свойство, так как позволяет сразу определить место, которое сервер счел ошибочным. В данном случае это ‘-10,10’, ошибка возникает из-за того, что параметр LIMIT не может быть отрицательным числом.

Однако, бывает и так, что цитируемый кусок запроса не содержит синтаксической ошибки. Это означает, что данная часть запроса находится не на своем месте из-за чего весь запрос становится синтаксически неверным. Например, отсутствует разделитель между двумя запросами, пропущен кусок запроса, невидимый символ в дампе и т.д. Неудобством таких ситуаций является то, что сообщение об ошибке не содержит исходный запрос. Действия по исправлению зависят от контекста возникновения ошибки. Таковых всего 3:

1. Запрос в редакторе.

Самый простейший случай — вы пишите свой запрос в редакторе. Если причина не опечатка, то:

Смотреть в документации синтаксис команды для вашей версии сервера MySQL.

• mysql_query() выполняет содержимое как одну команду, добавление delimiter приведет к error 1064 с цитатой, начинающейся со слова delimiter
• phpmyadmin удаляет слово delimiter из-за чего возникает error 1064 с цитатой, начинающейся с переопределенного разделителя
• в MysqlQueryBrowser напротив необходимо использовать delimiter.

2. Перенос базы на другой сервер.

У вас есть дамп (т.е. файл с расширением .sql) и при попытке его импортировать вы получаете ошибку 1064. Причины:

В различных версиях набор ключевых слов и синтаксис может немного отличаться. Наиболее распространенный случай: команда create table, в которой ключевое слово type было заменено на engine. Например, если вы получаете ошибку:

Это означает, что вы переносите базу в пятую версию сервера MySQL, в котором ключевое слово TYPE не поддерживается и его нужно заменить на ENGINE.

Редко бываю случаи, когда перенос идет на старый (

3.23) сервер, который кодировки не поддерживает. Тогда ошибка будет иметь вид:

Такое может произойти, если вы переносите базу с хостинга на локальный комп, где стоит древняя версия MySQL. Лучшим решением в данном случае будет не править дамп, а обновить MySQL.

Часто проблемы вызваны тем, что дамп делается неродными средствами MySQL (например, phpmyadmin) из-за чего в нем могут быть BOM-маркер, собственный синтаксис комментариев, завершения команды и т.д. Кроме того при использовании того же phpmyadmin возможна ситуация при которой из-за ограничения апача на размер передаваемого файла команда будет обрезана, что приведет к ошибке 1064. Например, если вы получаете ошибку:

Значит ваш дамп содержит BOM-маркер. Это три байта в начале файла, помогающие программе определить что данный файл сохранен в кодировке UTF-8. Проблема в том, что MySQL пытается интерпретировать их как команду из-за чего возникает ошибка синтаксиса. Нужно открыть дамп в текстовом редакторе (например, Notepad++) и сохранить без BOM.

Для избежания подобных проблем при создании дампа и его импорте лучше пользоваться родными средствами MySQL, см http://sqlinfo.ru/forum/viewtopic.php?id=583

3. Некорректная работа сайта.

Если во время работы сайта появляются ошибки синтаксиса, то, как правило, причина в установке вами сомнительных модулей к вашей cms. Лучшее решение — отказаться от их использования. Еще лучше предварительно проверять их работу на резервной копии.

Пример. Движок dle 7.2, поставили модуль ,вроде бы все Ок, но:

MySQL Error!
————————
The Error returned was:
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 ‘AND approve=’ 1 ‘ AND date < ‘ 2008 -10 -04 04 : 34 : 25 ‘ LIMIT 5’ at line 1

Error Number:
1064
SELECT id, title, date , category, alt_name, flag FROM dle_post WHERE MATCH ( title, short_story, full_story, xfields, title ) AGAINST ( ‘Приобретение и оплата скрипта ‘ ) AND id != AND approve= ‘1’ AND date < ‘2008-10-04 04:34:25’ LIMIT 5

В данном примере мы видим, что причина ошибки в отсутствии значения после «id ! php» style=»font-family: monospace;»> $db -> query ( «SELECT id, title, date, category, alt_name, flag FROM » . PREFIX . «_post WHERE MATCH (title, short_story, full_story, xfields, title) AGAINST (‘$body’) AND id != » . $row [ ‘id’ ] . » AND approve=’1’» . $where_date . » LIMIT » . $config [ ‘related_number’ ] ) ;

Далее можно искать откуда взялась переменная $row и почему в ней нет элемента ‘id’ и вносить исправления, но лучше отказаться от использования такого модуля (неизвестно сколько сюрпризов он еще принесет).

How can I fix MySQL error #1064?

When issuing a command to MySQL, I’m getting error #1064 «syntax error».

What does it mean?

How can I fix it?

3 Answers 3

• 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:

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 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:

If you write this this in two lines

then you can add echo $query; or var_dump($query) to see that the query actually says

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):

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:

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”.

The identifier quote character is the backtick (“ ` ”):

If the ANSI_QUOTES SQL mode is enabled, it is also permissible to quote identifiers within double quotation marks: