Support

Site Restoration

#32969 Incorrect table name '' SQL=DROP TABLE IF EXISTS ``

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a

Latest post by on Thursday, 04 June 2020 17:17 CDT

Saturday, 02 May 2020 23:57 CDT

tomarriola
Im trying to restore my site to a subdomain for use as a staging server but on restore the db restore gives me an error
Incorrect table name '' SQL=DROP TABLE IF EXISTS ``

The db user has full r/w rights.

I looked through your forum to find the answer but found no good direction.
Thanks
Tom

Sunday, 03 May 2020 01:53 CDT

tomarriola
I tried db restore with the option selected to back-up tables and got this error

Database error processing line 20
Database server error reply:
ErrNo #1005
Can't create table 'xxx-2020-staging.j16_acym_step' (errno: 121)

Monday, 04 May 2020 02:42 CDT

nicholas
Please note that you are using an older, testing version of Akeeba Backup (7.0.0.rc1) we no longer provide support for. The issue you have reported is known and has been fixed months ago.

You can solve this problem by updating Akeeba Backup, taking a new backup and restoring that to your staging server. Kindly note that the current version at the time of this writing is 7.1.3.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 05 May 2020 02:19 CDT

tomarriola
I am *now* using the latest version on the live and staging site. Now on db restore I get a new error message. See below. Can you help?
Tom

Database error processing line 555
Database server error reply:

ErrNo #1005
Can't create table 'crimescene-2020-staging.j99_acym_step' (errno: 121)
SQL=CREATE TABLE `j99_acym_step` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`triggers` longtext,
`automation_id` int(11) NOT NULL,
`last_execution` int(11) DEFAULT NULL,
`next_execution` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `fkj99_acym__step1` (`automation_id`),
CONSTRAINT `fkj99_acym__step1` FOREIGN KEY (`automation_id`) REFERENCES `j99_acym_automation` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8
Raw query text:

CREATE TABLE `j99_acym_step` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`triggers` longtext,
`automation_id` int(11) NOT NULL,
`last_execution` int(11) DEFAULT NULL,
`next_execution` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `fkj99_acym__step1` (`automation_id`),
CONSTRAINT `fkj99_acym__step1` FOREIGN KEY (`automation_id`) REFERENCES `j99_acym_automation` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8

Tuesday, 05 May 2020 02:37 CDT

nicholas
Yes, I can help you.

If you are restoring on the same database as your original site: please create a new database for your staging site. AcyMailing is using an unorthodox convention for naming its foreign key constraints which will make it impossible to restore them correctly on a database that contains the tables of the site that was backed up. This is a bug in AcyMailing.

If you are restoring on a new database please make sure that during the database restoration step you select the Suppress Foreign Key Checks option in the right hand panel. This is selected by default.

There is a small chance that there's an error in the way AcyMailing created its database indices but I think it's unlikely on the basis that we'd have already heard about it from other people. Most likely your problem is restoring to the same database as the original site due to AcyMailing's bug in naming foreign key constraints (using the convention fkPREFIX_NAME instead of PREFIX_fk_NAME because apparently one of its developers completely missed the point of having a prefix or why it's called a prefix and not "something to put wherever you want in a database entity's name with reckless abandon" – but I digress).

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Thursday, 04 June 2020 17:17 CDT

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
Edited by on 2020-06-04 17:17 CDT

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!