Support

Akeeba Backup for WordPress

#24358 – ErrNo #0

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Wednesday, 03 February 2016 16:25 CST
I'm attempting to migrate changes made on our Development server to our Test/Staging Server and I see the following error:

Database server error reply:

ErrNo #0
SQL=CREATE TABLE `wp_fileaway_downloads` (`id` int(11) NOT NULL auto_increment ,`timestamp` varchar(255) NULL ,`file` varchar(1000) NULL ,`uid` int(11) NULL ,`email` varchar(255) NULL ,`ip` varchar(255) NULL ,`agent` varchar(255) NULL ,`notified` bit(1) NULL DEFAULT 'b\'0\'' , PRIMARY KEY (`id`), KEY `uid` (`uid`) USING BTREE) ENGINE=InnoDB DEFAULT COLLATE utf8mb4_unicode_ci

Raw query text:
CREATE TABLE `#__fileaway_downloads` (`id` int(11) NOT NULL auto_increment ,`timestamp` varchar(255) NULL ,`file` varchar(1000) NULL ,`uid` int(11) NULL ,`email` varchar(255) NULL ,`ip` varchar(255) NULL ,`agent` varchar(255) NULL ,`notified` bit(1) NULL DEFAULT 'b\'0\'' , PRIMARY KEY (`id`), KEY `uid` (`uid`) USING BTREE) ENGINE=InnoDB DEFAULT COLLATE utf8mb4_unicode_ci

With existing tables is set to DROP and "Suppress foreign key checks", "No auto value on zero", and "Allow UTF8MB4 auto-detection" are selected

Looking at the tables in the DB it looks like the restore operation succeeds in dropping the table prior to the creation attempt.


After reading several articles regarding ErrNo #0 which mention permission issues I attempted running the following SQL with CLI as the wordpress user I'm entering in the ANGIE dialogs. No errors

This was the result of running
show create table wp_fileaway_downloads;
on the Dev server that we used to create the JPA

CREATE TABLE `wp_fileaway_downloads` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`timestamp` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`file` varchar(1000) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`uid` int(11) DEFAULT NULL,
`email` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`ip` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`agent` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`notified` bit(1) DEFAULT b'0',
PRIMARY KEY (`id`),
KEY `uid` (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

As the plugin that the table supports is no longer installed or in use I have deleted the table from the DEV server, created a new backup and was able to restore. This is more to alert you to a potential problem.

-Paul Bergman
Custom Fields
Which documentation pages did you read? None
Which troubleshooter articles did you read? 23072
Have you searched the tickets before posting? Yes
Did you already run the log analyser (ALICE)? Not Applicable
WordPress version (in x.y.z format) 4.4.2
PHP version (in x.y.z format) 5.5.9
MySQL/database version 5.5.44
Host (who is hosting your site, not your domain) in-house Ubuntu
Akeeba Backup version (x.y.z format) 1.6.2
DWDLicense
Thursday, 04 February 2016 01:36 CST
I have the suspicion that your target server does not support utf8mb4.

Please note that if you are transferring a site FROM a plain utf8 server TO a utf8mb4-capable server the transfer will work and you can use the "Allow UTF8MB4 auto-detection" option to upgrade your tables to utf8mb4. However if you are transferring FROM a utf8mb4-capable server TO a plain utf8 server it will NOT work.

This is not something we can work around, it's a limitation of MySQL: utf8mb4 data can represent (four byte) characters that plain old 3-byte utf8 cannot. That was the reason WordPress migrated to utf8mb4. If you try to insert a four byte character to a plain old 3-byte utf8 table MySQL will truncate the data without asking you and without an indication of error! Therefore if we allowed downgrading utf8mb4 to plain old utf8 you'd end up with truncated data, i.e. a broken site.

The only corrective course of action I can see is making sure your target server supports utf8mb4. Please note that even if you manually downgraded the tables on your source server to utf8, WordPress would automatically upgrade them back to utf8mb4 the next time it installs an update.


Nicholas K. Dionysopoulos

Lead Developer and Director



Greek: native

English: excellent

French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



nicholas
Saturday, 05 March 2016 17:20 CST
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.
system
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Upcoming unavailability: We will be closed December 23rd, 2019 19:00 to January 3rd, 2020 10:00 Cyprus timezone (EEST) due to the Holiday Season. You will not be able to file new support tickets or reply to existing ones.

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!

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.