I am importing a fairly large database. The .sql
file has almost 1,000,000 lines in it. Problem is that I am getting a syntax error when trying to import the database. It says:
ERROR 1064 (42000) at line 8428420: 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 ‘
Fatal error: Maximum execution time of 600 seconds exceeded in
Normally I’d just open the .sql file and fix the error. But my computer is really struggling to open this file.
Is there any way I can ignore errors when importing a MySQL database?
A.L
9,97910 gold badges65 silver badges97 bronze badges
asked Jun 29, 2012 at 13:49
1
Use the --force
(-f
) flag on your mysql import. Rather than stopping on the offending statement, MySQL will continue and just log the errors to the console.
For example:
mysql -u userName -p -f -D dbName < script.sql
luchaninov
6,7526 gold badges59 silver badges75 bronze badges
answered Sep 10, 2014 at 17:21
Craig BoobarCraig Boobar
3,7611 gold badge10 silver badges3 bronze badges
2
I have an sql file that i exported from phpmyadmin on another computer. I tried to import the file on this computer and I get this error:
Error
SQL query:
--
-- Database: `phplogin`
--
-- --------------------------------------------------------
--
-- Table structure for table `people`
--
CREATE TABLE IF NOT EXISTS `people` (
`id` INT( 11 ) NOT NULL AUTO_INCREMENT ,
`name` VARCHAR( 25 ) NOT NULL ,
`age` INT( 11 ) NOT NULL ,
`testvar` VARCHAR( 5 ) NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = MYISAM DEFAULT CHARSET = latin1 AUTO_INCREMENT =3;
MySQL said:
#1046 - No database selected
asked Jul 30, 2011 at 1:31
The error is because you either didn’t select a database on the left side to import to, and/or you didn’t create the empty database first. Create a database in phpMyAdmin called «phplogin», select it on the left side, and then run the import.
answered Aug 3, 2011 at 0:17
ClowerwebClowerweb
1,7462 gold badges14 silver badges13 bronze badges
2
Append the following line to the beginning of your sql file
CREATE DATABASE phplogin;
These problems can be resolved by exporting the SQL file while being outside the database.Then phpmyadmin automatically appends the above statement to the SQL file
answered Mar 13, 2013 at 20:17
funtimefuntime
6521 gold badge5 silver badges20 bronze badges
I’ve had this problem just this moment and none of the above answers solved my problem. Eventually, I ran the export again and the resulting .sql file was much larger. So the problem was a faulty export which resulted in an incomplete SQL file. The necessary statements would have been truncated in this case.
answered Jun 9, 2017 at 19:20
При импорте дампа базы данных возникает ошибка:
#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 96
Импорт выполняется с помощью PhPMyAdmin
-
Вопрос заданболее трёх лет назад
-
4071 просмотр
Пригласить эксперта
если эта копия с работающей базы, попробуйте еще раз скопировать и загрузить ее в чистую базу где нет таблиц от предыдущего переноса.
А так сообщение говорит что в строке 96 ошибка в синтаксисе, возможно что версии MySQL разные.
если бекап снимался mysqldump, то заливать лучше через консольный mysql.
обычно ошибки вылазиют, если нет понятия о часовом поясе, который обозначен в дампе.
У PHPMyAdmin есть ограничение на размер импортируемого файла, по умолчанию 2Mb. Попробуйте грузить таблицы по одной.
Если есть доступ к консоли, то попробуйте импортировать через mysql# mysql -u root -p < dump.sql
Почему-то хостинг или PHPMyAdmin не отдавал нормально базу, дамп скачивался неполностью. Сделал резерную копию и скачал через фтп, получилось
-
Показать ещё
Загружается…
12 июн. 2023, в 15:59
2000 руб./за проект
12 июн. 2023, в 15:24
1500 руб./за проект
12 июн. 2023, в 15:01
5000 руб./за проект
Минуточку внимания
-
Offline
DKraev
<i>(aka gft)</i>
=> Cпециалист <=- Регистрация:
- 16.08.2008
- Сообщения:
- 1 627
- Симпатии:
- 219
- Пол:
- Мужской
Приветствую всех. За время моего пребывания на данном форуме довольно часто возникали вопросы по ошибкам при импорте/экспорте базы данных MySQL (далее БД).
Вопросы примерно такие:
- После переноса (импорта) БД на хостинг на сайте сбилась кодировка. На локальном сайте все нормально;
- При переносе (импорте) БД возникает ошибка #1064 или другая;
- Пропадает текст после переноса (импорта) БД.
- Как перенести базу с Denwer на хостинг (или наоборот)
- и т.д
Прежде чем публиковать подобный вопрос на форуме, настоятельно рекомендую прочитать данный пост полностью, и что самое главное — СДЕЛАТЬ все что здесь написано.
Большинство ошибок возникает именно из-за неправильного переноса, поэтому я опишу импорт/экспорт БД при помощи скрипта Sypex Dumper. Я буду описывать работу с Lite версией, с которой я успешно работаю уже больше трех лет. Хотел бы заметить что подобной информации полно в сети, однако у нас на форуме её нет. А так как большинство новичков при любой проблеме сразу идут сюда, а не в Google, то я решил написать этот небольшой мануальчик. Многим он поможет решить проблемы с переносом БД, а старожилов форума избавит от необходимости писать про Sypex Dumper снова и снова
В первую очередь скачиваем скрипт отсюда (utf-8, архив прикреплен к посту) либо с сайта разработчика (cp1251). Распаковываем архив. На выходе получим два файла — readme.txt (инструкция) и dumper.php (сам скрипт).
Экспорт БД с локального компьютера.
Я работаю на Denwer, но и для других должно быть точно так же по идее.
- Копируете файл dumper.php в корень сайта.
- Создаете новую папку, которую называете backup
- Набираете в браузере: www.adres_sayta.ru/dumper.php
- Вводите логин пользователя и пароль для базы данных, нажимаете «Применить»
- Чекбокс на «Backup/Создание резервной копии БД». Фильтр таблиц — оставляете пустым. Метод сжатия — GZip. Степень сжатия — 7. Нажимаете «Применить»
Наблюдаем, как весело бегут строчки вверх. Ваш дамп готов! Зайдите в ранее созданную папку backup, вы увидите архив примерно такой — amurka_2010-08-20_23-30.sql.gz — это и есть дамп БД.
Импорт БД на хостинг.
- Заливаете файл dumper.php в корень сайта на хостинг.
- Заливаете папку backup тоже в корень сайта. Права на папку — 777. Так же внутри данной папки будет лежать файл dumper.cfg.php — для него тоже выставляете 777
- Набираете в браузере: www.adres_sayta.ru/dumper.php
- Вводите логин пользователя и пароль для базы данных, нажимаете «Применить»
- Чекбокс на «Restore / Восстановление БД из резервной копии». БД — выбираете базу данных на хостинге. Файл — выбираете наш файл с дампом (пример — amurka_2010-08-20_23-30.sql.gz). Нажимаете «Применить».
Наш дамп имортируется на хост.
Перенос с хостинга на локалку выполняется аналогичным образом. Держать дампы на хостинге не рекомендую.
Ошибки.
Многие могут столкнуться с ошибкой «#2005: Unknown MySQL server host ‘имя’ (11004)» при импорте БД на хостинг. Это говорит о том, что неверно указан MySQL сервер. В dumper.php по умолчанию указан «localhost», на хостинге же может быть любой. Например — p1543.mysql.ihc.ru
Откройте файл dumper.php и в 34 строке найдите код:
-
define(‘DBHOST’, ‘localhost:3306’);
Вместо localhost:3306 впишите MySQL сервер вашего хостинга. Сохраните файл. Повторите попытку импорта.
———————————————-Несколько раз у меня не получалось залить базу на хост при помощи этого скрипта. Но это была проблема хостера. Решалось выставлением CHMOD 777 на папку www
———————————————-Я не рассматривал дополнительные настройки данного скрипта (кстати их довольно много). Данный мануал рассчитан на новичков, которые испытывают проблемы при переносе БД. Того что я написал достаточно для успешного переноса БД в 90% случаев. За более полной информацией — на сайт разработчика, либо в Google.
Вложения:
Последнее редактирование: 17.09.2010
-
Offline
woojin
Местный
Команда форума
=> Cпециалист <=- Регистрация:
- 31.05.2009
- Сообщения:
- 3 206
- Симпатии:
- 334
- Пол:
- Мужской
«+» тебе за описание
я приведу свой пример, немного по другому, но принцип то же
1. открываем phpMyAdmin
2. делаем дамп базы
3. потом в получевшемся файлике ищем такую строкуENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1, нас интересует выделенный фрагмент — эта строчка обычно идёт после функции создания таблицы т.е. CREATE TABLE IF NOT EXISTS
4. если не ясно в какой кодировке должна быть таблицы то этот выделенный фрагмент удаляем везде где он есть, сохраняем получившийся файл
5. импортируем дамп в другую базуP.S. если всё равно кякозяблики, то просто пере сохраняем файл с дампом в другой кодировке — меня этот метод ни когда ещё не подводил
-
Offline
mcsweb
Недавно здесь
- Регистрация:
- 25.01.2010
- Сообщения:
- 10
- Симпатии:
- 0
- Пол:
- Мужской
А вот нифига phpMyAdmin не вышло.
Ради науки решил перекинуть сайт с одного локального сервера на другой.
С ХАМРР на Денвер.
Как бы я не делал экспорт базу данных на ХАММРе в Денвере он не принимался.
В конце концов просто скопировал папку с таблицами с одного сервака на другой.
В результате сайт работает с ошибками.Буду пробовать скрипт от первого советчика.
Попробовал- результат тот же .
Хотя дампер.пхп отработал отлично.
Виднео что то в денвере не так совмещаетсяПоследнее редактирование: 23.08.2010
-
Offline
woojin
Местный
Команда форума
=> Cпециалист <=- Регистрация:
- 31.05.2009
- Сообщения:
- 3 206
- Симпатии:
- 334
- Пол:
- Мужской
интересно по чему не сработал ни один ни второй вариант?!
есть вариант воспользоваться компонентом http://www.akeebabackup.com/ это следующая версия joomlapack
в описании почитай про совместимость компонента с версиями php
-
Offline
VashMaster
Недавно здесь
- Регистрация:
- 19.08.2010
- Сообщения:
- 19
- Симпатии:
- 1
- Пол:
- Мужской
Тоже всегда делаю всё аналогично посту ТС. Пользуюсь утилиткой дампер. Проблем обычно не было. Но вот при переносе сайта на Joomla почему-то появились
Сделал дамп, потом этим же дамперов восстановил дамп. Но всё равно появились кракозябры.
Проблему удалось решить только с помощью добавления команды:-
mysql_query(«SET NAMES cp1251»);
в файле index.php на фронт энде и бекенде. Добавил после вызова функции
-
$mainframe->initialise();
Получилось примерно так:
-
$mainframe->initialise();
-
mysql_query(«SET NAMES cp1251»);
Только тогда всё стало ОК. Если не поможет, то, возможно, у вас используется кодировка UTF. Пробуйте…
p.s. При работе с «дампером» редко бывают проблемы с кодировкой, но вот случилось Видимо, я не зря недолюбливаю Джумлу
-
Offline
DKraev
<i>(aka gft)</i>
=> Cпециалист <=- Регистрация:
- 16.08.2008
- Сообщения:
- 1 627
- Симпатии:
- 219
- Пол:
- Мужской
Модераторы, закрепите тему. Подобные вопросы продолжают сыпаться. До второй страницы (куда уже спустилась эта тема) пользователям дочитывать уже лень… По всей видимости что такое поиск они тоже не знают…
-
Offline
Владимир.
Недавно здесь
- Регистрация:
- 25.02.2011
- Сообщения:
- 1
- Симпатии:
- 0
- Пол:
- Мужской
Не хотел ставиться русский язык, вылезали кракозябры. Как я только не пересохранял файлы и базы ничего не помогало… Снес снова все и сделал по главной инструкции через Sypex и чудо таки случилось!!!
Хочу добавить:
При создании на локальном компьютере дампа используем логин и пароль базы данных, созданной в самом начале. (не путать с логином для входа в админку джумлы)
При запуске на хостинге необходимо указать логин и пароль к базе данных, лежащей у хостера.
Дальше необходимо просто перенести все файлы с локального компьютера на сервер хостера и поправить файл configuration.php
А еще у меня возник вопрос относительно приключений с кодировками…
Не может ли сама операционка выдавать эти сюрпризы?
Когда я первый раз заливал этот же сайт на хостинг у меня все прошло гладко и не возникло проблем.
После того как сайт сломали, я переустановил винду, денвер и джумлу на 1.5.22. Вот и думаю, что именно повлияло на неправильное отображение символов… -
Offline
DKraev
<i>(aka gft)</i>
=> Cпециалист <=- Регистрация:
- 16.08.2008
- Сообщения:
- 1 627
- Симпатии:
- 219
- Пол:
- Мужской
Не знаю, работал и на XP и на семёрке — проблем не возникало. Но может быть потому что я всегда пользуюсь Sypex… Чаше всего траблы вылезают именно на хостинге… НА локалке, как уже сказал, всегда всё ровно…
-
Offline
oceay
Недавно здесь
- Регистрация:
- 12.09.2011
- Сообщения:
- 1
- Симпатии:
- 0
- Пол:
- Мужской
Спасибо огромное, gft !!!! Сначала многое кажется непонятным, но начинаешь делать согласно инструкции и всё получается само собой. Ещё раз спасибо!
-
Offline
woojin
Местный
Команда форума
=> Cпециалист <=- Регистрация:
- 31.05.2009
- Сообщения:
- 3 206
- Симпатии:
- 334
- Пол:
- Мужской
это ты админу отправь, я не могу этого сделать!!!
Поделиться этой страницей
Невозможность загрузки (импорта файла базы данных) в phpMyAdmin в панели управления Vesta (CentOS). Сообщение о превышении максимально-допустимого к загрузке размера файла (upload_max_filesize).
Панель управления сайтами Vesta мне понравилась с первого раза. Бесплатная и ничего лишнего, очень минималистично и при этом функционально. Однако уже не первая ошибка в «Весте», которая заставила меня поломать голову. На этот раз проблема касалась upload_max_filesize. Значения никак не хотели меняться. Но давайте по порядку:
Если значения upload_max_filesize поддаются изменению
Ошибка в базе данных на английском:
You probably tried to upload a file that is too large. Please refer to documentation for a workaround for this limit.
Для исправления надо перейти во вкладку Server. Дальше навести мышку на httpd, выбрать CONFIGURE. Перейти во вкладку HTTPD CONFIGURE PHP.INI.
И здесь поменять значение upload_max_filesize.
Если значения upload_max_filesize не изменяются
Вообще-то по-умолчанию значения должны меняться через панель, но это у меня не всегда происходило. Сам файл конфигурации в панели однажды оказался пустым.
Изменение в его значениях ни к чему не приводили.
Пришлось менять всё вручную. Сначала я нашел все файлы php.ini у себя на сервере:
Было не мало файлов:
/tmp/tmp.sfsdf48wmWo4vX/vesta/src/rpm/conf/php.ini
/etc/php70/php.ini
/etc/php71/php.ini
/etc/php.ini
/etc/php52/php.ini
/etc/php54/php.ini
/etc/php55/php.ini
/etc/php56/php.ini
/etc/php53/php.ini
Из них данные были только в файлах /etc/php.ini и в /tmp/. Остальные оказались пустыми. В поисках решения я даже удалил все файлы и тоже ничего не изменилось.
Решение как изменить значение upload_max_filesize в панели Vesta (CentOS) я всё-таки обнаружил. Значения хоть и изменились, но MySQL по-прежнему не хотел импортировать файл в 3 мб, ругаясь на размер файла.
Как изменить upload_max_filesize в файле php.ini панели управления Vesta (CentOS)
Создаем файл на сервере:
Заходим в него через адресную строку браузера:
https://ploshadka.net/info.php
Находим строчку:
Смотрим значение справа (у меня это было):
Значит сервер использует конфигурацию PHP по адресу — /etc/php56/php.ini
Копируем в этот файл конфигурацию по-умолчанию:
cp /etc/php.ini /etc/php56/php.ini
Правим сам файл /etc/php56/php.ini, изменяем значение upload_max_filesize на 30М.
Перезагружаем сервер
Теперь в файле info.php отображается правильный upload_max_filesize.
Однако это не помогло импортировать базу данных MySQL. PhpMyAdmin всё также ругался на размер файла. Потому пришлось импортировать его через терминал.
Импорт базы данных MySQL через SSH
Если предыдущие способы не помогли импортировать базу данных MySQL, остаётся способ воспользоваться импортом через консоль.
Кладем файл в любую папку на сервере. При этом файл базы данных должен быть разархивированным. Затем воспользуемся командой:
mysql -u username -p database name < /path_to_MySQL_upload/name.sql
После ввода этой команды появится требование ввести пароль от базы данных. Вводим пароль и база будет импортирована.
Путь должен быть абсолютным, от корня главного раздела, например:
/home/admin/web/sait/public_html/