Ошибка 1064 mysql при импорте

Страницы 1

Чтобы отправить ответ, вы должны войти или зарегистрироваться

Страницы 1

Чтобы отправить ответ, вы должны войти или зарегистрироваться

I exported a database as a backup that was working fine. When I imported the database to the same exact server, folder, etc. I got this error:

There is a chance that you may have found a bug in the SQL parser.
Please examine your query closely, and check that the quotes are
correct and not mis-matched. Other possible failure causes may be that
you are uploading a file with binary outside of a quoted text area.
You can also try your query on the MySQL command line interface. The
MySQL server error output below, if there is any, may also help you in
diagnosing the problem. If you still have problems or if the parser
fails where the command line interface succeeds, please reduce your
SQL query input to the single query that causes problems, and submit a
bug report with the data chunk in the CUT section below:
—-BEGIN CUT—- eNo1jUEKwjAURIXu/inmADHkpwYxu1JCu0iTmFQ9gYtushP09qaCs3oMjxmXc8wWI2PU8C5YMDSY
qayt7oiWT7l6CyON7NWxV5LpVjJiERgmF1aBu2vmY6sY5xwX11Ql9YXSMlicGhtKc9otEcs+1Es+
w2/19SY/hMniWen3Qd3hny8nMiDI
—-END CUT—-
—-BEGIN RAW—- ERROR: C1 C2 LEN: 1 2 11 STR:

MySQL: 5.5.30-30.1 USR OS, AGENT, VER: Win CHROME 5.0.29 PMA: 4.0.5
PHP VER,OS: 5.3.17 Linux LANG: en SQL:
—-END RAW—-

SQL query:

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 » at line 1

The only problem seems to be that my index page is missing content, the main content actually. All of these files are .sql.

I then dropped all my tables and imported the original database from April of last year. Obviously, this database is missing all the account info, order info, etc. for all my customers as well as all the changes that have been made to my products.

When I compare the two databases the first 11 lines seem to be the problem but I don’t know how to fix it. The first 11 lines of the file that DO NOT WORK are:

-- phpMyAdmin SQL Dump
-- version 4.0.5
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Sep 22, 2013 at 01:28 PM
-- Server version: 5.5.30-30.1
-- PHP Version: 5.3.17

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

The first 11 lines of the file that DOES WORK are:

-- phpMyAdmin SQL Dump
-- version 3.4.10.1
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Apr 09, 2012 at 05:50 AM
-- Server version: 5.1.61
-- PHP Version: 5.2.17

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

I hve tried to simply copy and paste the 11 lines from the working file to the file that does not work and get another error.

I know this is a long post and I apologize but I have been struggling with this for hours and really need some help.

Thanks

I have a SQL database that I want to import using phplyadmin but I am getting this error.

CREATE TABLE  `wp_commentmeta` (

`meta_id` BIGINT( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT ,
`comment_id` BIGINT( 20 ) UNSIGNED NOT NULL DEFAULT  '0',
`meta_key` VARCHAR( 255 ) DEFAULT NULL ,
`meta_value` LONGTEXT,
PRIMARY KEY (  `meta_id` ) ,
KEY  `comment_id` (  `comment_id` ) ,
KEY  `meta_key` (  `meta_key` ( 191 ) )
) ENGINE = Aria AUTO_INCREMENT =3843 DEFAULT CHARSET = utf8          
PAGE_CHECKSUM =1 DELAY_KEY_WRITE =1 TRANSACTIONAL =1;

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 ‘PAGE_CHECKSUM=1 DELAY_KEY_WRITE=1 TRANSACTIONAL=1’ at line 9

Дата: 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. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в бумажных изданиях допускается только с разрешения редакции.

• 2

Помог ли вам данный ответ?