Error 1064 42000 at line 1 you have an error in your sql syntax

Дата: 25.11.2013

Автор: Василий Лукьянчиков , vl (at) sqlinfo (dot) ru

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

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

SELECT mid, time, title, artist, download, view_count, rating, vote_num FROM dle_mservice WHERE category = ‘1’ AND approve = ‘1’ ORDER BY time DESC LIMIT -10,10;
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 ‘-10,10’ at line 1

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

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

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

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

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

  Обратите внимание: речь идет о версии сервера MySQL, а не клиента (phpmyadmin, workbench и т.д.). Версию сервера можно узнать выполнив команду select version();

• В MySQL допускается использование ключевых слов в качестве имен столбцов/таблиц, но при этом их необходимо заключать в обратные кавычки (там где буква ё на клавиатуре).
  Пример:

  select order from test;
  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 ‘order from test’ at line 1
  MariaDB [test]> select `order` from test;
  +——-+
  | order |
  +——-+
  |  NULL |
  +——-+

• По умолчанию ; разделяет команды. Если же нужно выполнить набор из нескольких инструкций как одну команду (например, при создании процедур, фунуций, триггеров), то в зависимости от используемого клиента может потребоваться переопределить разделитель с помощью DELIMITER, иначе интерпретация команды остановится на первой ; и будет ошибка синтаксиса. Пример:

  delimiter //
  create procedure test()
  begin
  set @a=1;
  select @a;
  end//

  Обратите внимание: DELIMITER это команда консольного клиента mysql, необходимость его использования зависит от того как вы передаете команду серверу. Например,:

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

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

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

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

  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 ‘TYPE=MyISAM CHARACTER SET `utf8`’ at line 29

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

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

  #1064 — You have an error in your SQL syntax near ‘DEFAULT CHARACTER SET cp1251 COLLATE cp1251_general_ci’ at line 1

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

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

  #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 ‘
  CREATE TABLE `jos_banner` (
    `bid` int(11) NOT NULL auto_increment,
    `ci‘ at line 1

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

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

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

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

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

В данном примере мы видим, что причина ошибки в отсутствии значения после «id != «

Обратите внимание: из процитированного сервером MySQL куска запроса причина ошибки не ясна. Если ваша CMS не показывает весь запрос целиком, то нужно в скриптах найти место где выполняется данный запрос и вывести его на экран командой echo.

Кусок кода, который отвечает за данный запрос это

$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’ и вносить исправления, но лучше отказаться от использования такого модуля (неизвестно сколько сюрпризов он еще принесет).

P.S. Если после прочтения статьи ваш вопрос с MySQL Error 1064 остался нерешенным, то задавайте его на форуме SQLinfo

Дата публикации: 25.11.2013

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

Oops!! Stuck with MySQL Error code 1064 SQL State 42000? We can help you in fixing it.

The SQL State Error 42000 occurs mainly due to the SQL syntax error or due to the outdated JDBC MySQL driver.

At Bobcares, we often get requests to fix MySQL errors, as a part of our Server Management Services.

Today, let’s see how our Support Engineers fix MySQL errors for our customers.

Why MySQL Error code 1064 SQL State 42000 occurs?

The MySQL Error code mainly occurs due to the SQL Syntax error. It happens when MySQL is unable to validate the commands.

The Syntax Error occurs due to many factors like mistyping the commands, deprecated or missing data from the database.

In some cases, the error occurs when the JDBC driver initializes the connection.

How we fix the MySQL Error code 1064?

Recently, one of our customers approached us saying that he is getting MySQL Error code 1064 SQL State 42000. On checking, we found an error in the SQL syntax.

Now, let’s see the main causes for this Error 1064 SQL State 42000 and how our Support Engineers fix them.

1. Using Reserved Words

The reserved words perform some specific functions within the MySQL engine.

Sometimes we receive the error while using the reserved words,  The error occurs when the MySQL is not meeting the exact requirements for using the particular keyword.

Create Table alter (first name, last name);

The alter is a reserved word. To fix the error 1064 with the reserved word we specify the alter word within backticks.

Create Table 'alter' (first name, last name);

2. Outdated JDBC driver

When the JDBC driver initializes the connection, it sends several commands to the MySQL server. At that time we may receive the MySQL Error code SQL State 42000.

The problem is that the commands were deprecated for some time which results in the error.

We fix the error by upgrading the JDBC MySQL driver to the latest version.

3. Mistyping and Missing of Data

The 1064 error occurs when the data is not found in the database or mistyping the commands.

In case, if the data is missing from the database, we manually add the data to the database. Also, we make sure that all the commands are spelled correctly.

[Need any assistance with SQL State 42000 Error codes? – We’ll help you]

Conclusion

In short, today we discussed in detail on MySQL Error code 1064 and saw how our Support Engineers find the fix for this error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

If you’ve been using WordPress for a while, you may have decided to get into more advanced database management. This often involves using the MySQL command line, which can, in turn, lead to confusing problems such as MySQL 1064 errors.

Fortunately, while resolving this error can be confusing at first due to its many potential causes, its solutions tend to be relatively simple. Once you determine the reason behind the database error you’re seeing, you should be able to fix it fairly quickly.

In this post, we’ll cover the various possible causes of the MySQL 1064 error. Then we’ll share solutions for each common situation, to help you get your database and your site back up and running.

Let’s get started!

Why the MySQL 1064 Error Occurs

The MySQL 1064 error is a syntax error. This means the reason there’s a problem is because MySQL doesn’t understand what you’re asking it to do. However, there are many different situations that can lead to this type of miscommunication between you and your database.

The simplest cause is that you’ve made a mistake while typing in a command and MySQL can’t understand your request. Alternatively, you may be attempting to use outdated or even obsolete commands that can’t be read.

In other cases, you may have attempted to include a ‘reserved word’ in one of your commands. Reserved words are terms that can only be used in specific contexts in MySQL. If you attempt to use them in other ways, you’ll be faced with an error.

It’s also possible that there is some data missing from your database. When you make a request via MySQL which references data that isn’t where it’s supposed to be, you’ll also see the 1064 error. Finally, transferring your WordPress database to another server can also lead to the same issue.

As you can see, there are many potential causes for this problem, which can make it tricky to resolve. Unless you’re in the process of moving your database or taking some other action that points to a specific cause, you’ll likely need to try a few different solutions before you land on the right one. Fortunately, none of them are too difficult to execute, as we’ll see next.

Oh no, you’re getting the MySQL 1064 Error…😭 Don’t despair! Here are 5 proven solutions to get it fixed immediately 🙏Click to Tweet

How to Fix the MySQL 1064 Error (5 Methods)

If you already have an idea of what’s causing your MySQL 1064 error, you can simply skip down to the resolution for your specific situation. However, if you’re not sure why the error has occurred, the simplest strategy is to try the easiest solution first.

In that case, we’d suggest testing out the five most likely fixes in the following order.

1. Correct Mistyped Commands

The good thing about MySQL typos is that they’re the simplest explanation for syntax issues such as the 1064 error. Unfortunately, they can also be the most tedious to correct. Generally speaking, your best option is to manually proofread your code and look for any mistakes you may have made.

We suggest using the MySQL Manual as a reference while you do so, double-checking anything you’re not sure about. As you might imagine, this can get pretty time-consuming, especially if you’ve been working in the MySQL command line for a while or if you’re new to this task.

An alternative to manually checking your work is to employ a tool such as EverSQL:

With this solution, you can simply input your MySQL to check for errors automatically. However, keep in mind that these platforms aren’t always perfect and you may still want to validate the results yourself.

2. Replace Obsolete Commands

As platforms grow and change, some commands that were useful in the past are replaced by more efficient ones. MySQL is no exception. If you’re working on your database following a recent update or have referenced an outdated source during your work, it’s possible that one or more of your commands are no longer valid.

You can check to see whether this is the case using the MySQL Reference Manual. You’ll find mentions of commands that have been made obsolete by each MySQL version in the relevant sections:

Once you’ve determined which command is likely causing the problem, you can simply use the ‘find and replace’ function to remove the obsolete command and add in the new version. For example, if you were using storage_engine and find that it no longer works, you could simply replace all instances with the new default_storage_engine command.

3. Designate Reserved Words

In MySQL, using a reserved word out of context will result in a syntax error, as it will be interpreted as incorrect. However, you can still use reserved words however you please by containing them within backticks, like this: `select`

Each version of MySQL has its own reserved words, which you can read up on in the MySQL Reference Manual. A quick find and replace should enable you to resolve this issue if you think it may be causing your 1064 error.

4. Add Missing Data

If your latest MySQL query attempts to reference information in a database and can’t find it, you’re obviously going to run into problems. In the event that none of the preceding solutions resolves your MySQL 1064 error, it may be time to go looking for missing data.

Unfortunately, this is another solution that can be quite tedious and has to be done by hand. The best thing you can do in this situation is to work backward, starting with your most recent query. Check each database it references, and make sure all the correct information is present. Then move on to the next most recent query, until you come to the one that’s missing some data.

5. Use Compatibility Mode to Transfer WordPress Databases

This final 1064 error solution isn’t as straightforward as the others on our list. However, if you’re migrating your WordPress site to a new host or otherwise moving it to a different server, you’ll need to take extra steps to avoid causing problems with your database.

The simplest solution is to use a migration plugin that includes a compatibility mode, such as WP Migrate DB:

This will enable an auto-detection feature that will make sure your latest site backup and database are compatible with multiple versions of MySQL. You can access the compatibility mode setting by navigating to Tools > Migrate DB > Advanced Options:

Check the box next to Compatible with older versions of MySQL before starting your site migration. This way, you should be able to avoid any issues during the process.

Summary

Database errors can throw a wrench in your plans, and may even compromise your website’s stability. Knowing how to resolve issues such as the MySQL 1064 error can help you react quickly, and minimize downtime on your site.

There are five methods you can try to fix the MySQL 1064 error when you encounter it, depending on its most likely cause:

1. Correct mistyped commands.
2. Replace obsolete commands.
3. Designate reserved words.
4. Add missing data.
5. Transfer WordPress databases in compatibility mode.

The ERROR 1064 (42000) mainly occurs when the syntax isn’t set correctly i.e. error in applying the backtick symbol or while creating a database without them can also create an error, if you will use hyphen in the name, for example, Demo-Table will result in ERROR 1064 (42000).

To remove the error, you need to use backtick around the database name properly or use
nothing. Following is the syntax wherein we haven’t used the backtick. This works correctly −

create database yourDatabaseName;

Since adding hyhen to the database name will result in an error. Let us implement it while creating the database name −

mysql> create database customer-tracker;

This will produce the following error since we used hyphen in the database name, which isn’t acceptable −

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 '-tracker' at line 1

Still, we can fix the hyphen in the database name by surrounding the name with backtick symbol −

mysql> create database `customer-tracker`;

This will produce the following output −

Query OK, 1 row affected (0.21 sec)

Now database is created successfully.

во первых запрос должен иметь примерно такой формат:

INSERT INTO `price` (`N`, `title`, `localsum`, `regionsum`, `rfsum`, `intersum`) VALUES  (1,'Poi',2,1000,1500,2000,4000)

обрати внимание, что кол-во полей не то, кол-во данных которые вставляются не соответствует кол-ву полей
во вторых у вас тип данных не правильный

`localsum` char(100) not null,
`regionsum` char(100) not null,
`rfsum` char(100) not null,
`intersum` char(100) not null,

эти поля должны быть int а не char
Если вы хотите именно строку, то цифры (при вставке) нужно оборачивать в кавычки

в третьих, раз `N` int not null auto_increment, то значение N можно или игнорировать при вставке, или передавать NULL

P.S. Строку вставки можно делать так:

INSERT INTO `price` SET `field`=1, `field2`=2, `field3`=3

так визуально понятней что куда вставляется

——
UPD

<?php
// соединение с базой:
chdir(dirname(__FILE__));
$dsn = 'mysql:host=localhost'.
    ';dbname=temp_development'.
    ';port='.
    ';connect_timeout=15';

$user = 'root';
$password = '123qwe#';
$db = new PDO($dsn, $user, $password);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);



$file = "./price.txt";# 'Poi',2,1000,1500,2000
# в файле я убрал последнее значение, т.к. для него нет соответствующей колонки в ДБ
if($fp = fopen($file, 'r'))
{
    $sql = "INSERT INTO `price` (`title`, `localsum`, `regionsum`, `rfsum`, `intersum`) VALUES ";
    $prepare = array();
    $insert = array();
    while($line = fgets($fp))
    {
        $line = trim($line);
        if(!$line)
            continue;
        # Читаю файл построчно, чтоб память не загадилась если файл содержит оч много данных

        // валидацию данных я не делаю
        array_push($prepare, implode(",", array_fill(0, 5, "?")));
        $insert = array_merge($insert, explode(",", $line));

    }
    $pr = $db->prepare($sql."( ".implode("), (", $prepare)." )");
    $pr->execute($insert);
}

этот код сгенерирует такой вот запрос в бд:

INSERT INTO `price` (`title`, `localsum`, `regionsum`, `rfsum`, `intersum`) VALUES ( ''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000'), (''Poi'','2','1000','1500','2000' )

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

SQL error 1064 – что делать?

Вам когда-нибудь приходилось видеть ошибку 1064 при работе с MySQL? Причем она указывает на некие синтаксические ошибки в SQL запросе, и эти ошибки могут быть совсем неочевидны – подробнее расскажем ниже.

Вместе и с нуля пройдем все этапы проектирования, администрирования, резервирования и масштабирования БД с использованием PostgreSQL, MS SQL и MySQL

Использование зарезервированных слов

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

Как этого избежать? Просто! Только потому что слово alter зарезервировано, это не значит, что его нельзя использовать – нужно просто по-особенному приготовить! Чтобы движок MySQL не воспринимал это слово как команду, мы будем просто использовать кавычки и оно взлетит:

Недостающая информация в таблице

Иногда какой-то части информации в таблице нет и это может вызвать эту ошибку, если запрос обращался к этим данным. К примеру, если в таблице был список сотрудников, и каждому был присвоен ID, было бы логично предположить, что запрос будет вызывать запись сотрудника вместе с номером ID, например:

Если пресловутый $id никогда не был правильно указан, запрос будет выглядеть для MySQL сервера следующим образом:

Т.к запрос по сути пустой, движок MySQL будет выдавать ту самую ошибку 1064. Исправляется это следующим образом – вам нужно каким-то образом вызвать конкретную запись и добавить недостающую информацию, причем сделать это не так просто: если пытаться вызвать запись по уникальному номеру, скорее всего вы увидите точно такую ошибку. Можно с помощью phpMyAdmin вручную выбрать необходимую строку и добавить нужную информацию.

Опечатки в командах

Одной из самых частых причин ошибки 1064 являются опечатки. И иногда можно десять раз посмотреть на команду и не увидеть опечатки – как пример ниже с командой UPDATE:

Соответственно, проверяйте команды свежим взглядом и старайтесь не пропускать такого. Правильный вариант будет выглядеть так:

Устаревшие команды

Некоторые команды устарели, и в новых версиях MySQL начинают выдавать хорошо знакомую нам ошибку. К примеру, команда ‘TYPE’ была признана устаревшей в MySQL 4.1 и была полностью удалена в MySQL 5.1, где при попытке использовать ее вы можете видеть ту самую ошибку. Вместо нее необходимо использовать команду ‘ENGINE’.

Ниже неверный вариант:

А вот правильный, модный и современный вариант (как оно должно быть, чтобы не было ошибки):

Заключение

Как можно видеть, для одной несчастной ошибки, указывающей на синтаксис, может быть целый ряд разных причин. Так что когда вы видите подобную ошибку – вспомните эту статью и проверьте все возможные варианты ?

Вместе и с нуля пройдем все этапы проектирования, администрирования, резервирования и масштабирования БД с использованием PostgreSQL, MS SQL и MySQL

Полезно?

Почему?

😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.

😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.

Источник

MySQL error 1064

Автор: Василий Лукьянчиков , vl (at) sqlinfo (dot) ru

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

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

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

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

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

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

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

Обратите внимание: речь идет о версии сервера MySQL, а не клиента (phpmyadmin, workbench и т.д.). Версию сервера можно узнать выполнив команду select version ( ) ;

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 != «

Обратите внимание: из процитированного сервером MySQL куска запроса причина ошибки не ясна. Если ваша CMS не показывает весь запрос целиком, то нужно в скриптах найти место где выполняется данный запрос и вывести его на экран командой echo.

Кусок кода, который отвечает за данный запрос это

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

Источник