19 ноября 2006 в 2:00
Сделал дамп с помощью модуля backup. Пытаюсь залить локально но почему то не цепляет. Пишет "Нет SQL запроса"
В ручную если копировать кусками и вставлять то все ок, но как-то муторно
Размер базы 12,2 мб
???
Комментарии
Тоже такое было..Замучился сначала..
Наверно Денвер локально?
я вылечил тем что дамп стал делать пакованным в tar.gz и потом также через tar.gz заливать локально..
Сейчас вроде нормально..
--
С уважением, Аркадич
"Убей в себе Денвер" (с) не помню кто
mysql < файл_с_базой_данных.sql
таки убил и ведь помогло!
Спасибо!
перед дампом базы, я очищаю таблицы cache и watchdog
саму базу сжимаю в gz
В настройках экспорта phpMyAdmin необходимо Отключить все дополнительные комментарии, иногда помогает.
я использовал при такой проблеме dumpex потом все нормально заливалось )
Денвер здесь ни при чем. Такая байда может быть везде где используется для работы с базами данных инструментарий на базе PHP (в данном случае Phpmyadmin). В настройках по умолчанию в файле php.ini задается максимальный объем загружаемого файла в 2Мб. Этого мало, а потому в данном случае рекомендуется увеличить размер до необходимых 16Мб. Для этого ищем строчку:
upload_max_filesize = 2M
и подставляем вместо 2M, - 16M.
P.S. Практика показывает что для работы друпала лимит памяти в 8Мб это, мягко скажем, маловато. Ищем в этом же конфиге php.ini строку:
memory_limit = 8M
И заменяем значение по умолчанию 8M на 16M. Тем самым вы избежите ситуации когда друпал вылетает с ошибкой "Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate совсем-децел bytes) бла-бла-бла on line бла-бла-бла" при попытки, скажем, врубить/вырубить сразу пяток модулей или забекапить базу используя модуль друпала dba.
2 Ne01eX:
ещё нужно в php.ini изменить строчку (8 на 32 например)
post_max_size = 8M
иначе выставив upload_max_filesize больше 8М всё равно максимум загружать базы можно будеть до 8 М.
а memory_limit в Денвере по дефолту 128М
супер! спасибо ребята,помогли
Сам пользуюсь этим инструментом. Рекомендую.
Да, утилитка хороша, но авторы похоже издеваются - последняя доступная версия - 1.0.8 от 2006 года. На странице "История версий" написано: "Версия 1.1.0 [готовится к выпуску]" и это сообщение висит тоже, наверное с 2006. А теперь они в шапку ещё добавили "версия 2.2.0"!
Наверное они просто забывают добавлять на сайт новые ссылки ссылки для скачки
Честно говоря, мне без разницы. Свои функции она выполняет исправно, база переносится "на ура". А что ещё нужно?
Сейчас 2.0.0 или уже пошел обратный отсчет?
Интересно когда же они выпустят таки в свободное плавание свеженький сайпекс...
Обшибся, конечно.
А, что, "несвободное" плавание существует? Новый скрипт можно купить?
Мне кажется новый скрипт пока доступен только для шапки ))) наверное она его тестирует... инфы вообще никакой
ребята. была та же ппроблема. так и не решил
Дампер загружает только 81 таблицу из 157 и все. остальрные вручную загоняю...
и это при том. что в my.cnf на денвере поставил max_packet_limit 64мб в двух местах. а до этого вообще ошибку выдавал сайпекс дампер...
что же делать, база в зипе 1.4 мб, а гз 17 мб. и такая фигня...
понмю када то давно все получалось
Непонятно,почему пользуетесь левыми утилитами,когда есть такой ШИКАРНЫЙ модуль,как backup_migrate.Наверное сотню раз уже бекапил и восстанавливал-ни одного сбоя.
про Sypex Dumper отдельная история
мы бэкамили и заливали друпаловскую базу данных одного большого сайта - база на почти 200 метров была
дампер допустил фатальную оплошность - user id, или попросту uid анонимуся оказался не равным 0
вроде бы и ничего да есть одно но
uid анонимуса жестко зашит в ядро, в частности в модуль сессий, и там он должен быть равен 0(ноль), и без вариантов
таким образом после обработки дампером мы долго бились головой об стену пытаясь решить проблему с несохранением сессии у анонимуса
с тех пор я использую только mysqldump
дешево и сердито, нет ничего лучше стандартной тулзы
P.S. надеюсь с версией 2.0, если выйдет, эта проблема решится, но сейчас - недостаточно надежно