Штатным методом восстанавливаю бекап из админки и получаю такую ошибку.
Попробуйте залить бекап напрямую в базу через пхпмайадмин.
А вообще после первой такой проблему больше не рисковал делать бекапы средствами Карта.
Точнее делаю только файлы, а БД через ssh/
По разному бывает, я всегда три бэкапа делаю, из админки, supexdumper, и pma. так вот было раз, что только из админки и смог восстановить, а два других загибались на одной и той же таблице, сейчас уже не вспомню на какой. но то что делаю три бэкапа базы теперь постоянно - это факт!
а по сути - к АВ надо, что там у них за внешние ключи, и как это обойти.
phpMyadmin выдает эту же ошибку. Но там можно отключить проверку внешних ключей руками. Тогда ошибка пропадает, но вылетаю по таймауту
а почему просто не через консоль?
mysqldump
В моем случае удалось решить дописав руками в дамп базы в бекапе строки:
SET FOREIGN_KEY_CHECKS=0; в начале
SET FOREIGN_KEY_CHECKS=1; в конце
Потом залил бекап на сервер и развернул штатно через админку cs_cart.
Но вопрос откуда эти ограничения ключей и почему они штатно не отрабатываются остается.
может @alexbranding @ab.developer смогут подсказать?
Т.к. во всем дампе только у таблицы “cscart_ab__ecw_comparison_page_descriptions” прописан CONSTRAINT
У меня тоже было подобное, восстановили именно из админки.
Я бы не рассчитывал на бекап из админки, а сразу смотрел в сторону решений на стороне сервера. Уже хотя бы потому что если что-то сломается, админка вероятно так же работать не будет. В силу ограниченной применимости, лучше не рассматривать это штуку как бекап. Наверное, эта штука может быть полезна для каких-то задач, особенно на небольших сайтах. Но именно в каких-то случаях, а не как полноценный бекап.
Написал на их форуме, тут как я понял это уже не актуально. Это таблицы их модуля расширенного сравнения товаров. Не знаю ответят ли.
Так, если кто потом наткнется на данный вопрос, то есть ответ от разработчика.
принято, будет исправлено в следующей версии.
Пока как выход это
SET FOREIGN_KEY_CHECKS=0;
