Some SQL queries have failed to execute but you chose to ignore them. You can review them and their failure reason after the end of the restoration by looking into the following log file:
The database restoration was successful
The database restoration completed but some queries failed to run
Your restored site may not work properly unless you manually rectify these issues. Please review the failed queries and the reason they failed by looking into the log file:
Click the button below to proceed to the next step
An error occurred while restoring the database. The error message can be found below. Click on the × button at the top right of this dialog message to close it and return to the database restoration page.
Restoration of site's main database
This is usually MySQLi (with the trailing "i")
The host name or IP address of the database server (usually: localhost). Please note that localhost and 127.0.0.1 are very different as far as MySQL is concerned; you may have to try both to see which works with your database server. If your server is using a non-standard port, append it after the hostname prefixed with a colon, e.g. 127.0.0.1:1234 to use a database server on 127.0.0.1 listening to port 1234.
The username you use to connect to your database. Most hosts using cPanel, Plesk and other major hosting panels will give usernames like abcdef_username, where abcdef is your hosting control panel username. If unsure, please ask your host.
The password you use to connect to your database.
The name of your database. Most hosts using cPanel, Plesk and other major hosting panels will give database names like abcdef_username, where abcdef is your hosting control panel username. If unsure, please ask your host.
The prefix of all restored database tables which had a prefix at backup time. The prefix used for the site's main database will also be written to your WordPress wp-config.php file. Please note that some extensions may misbehave or even completely crash your site if you change your database table name prefix when restoring / transferring your site.
Select what to do with existing tables. “Drop” will delete existing tables with the same names as tables being restored. “Backup” will rename existing tables with the same names as tables being restored, changing their prefix to bak_. “Drop Same Prefix” will drop all tables with the same prefix, even if they are not included in the backup being restored. “Drop All” will drop all tables, even with a different prefix. The latter two options are DANGEROUS and should be used with EXTREME CAUTION.
Disables MySQL's foreign key checking while the restoration is in progress. This is mandatory when you are restoring a database which uses table-level relations (foreign keys). If unsure, leave this checked; it won't do any harm.
Only valid for MySQL databases. Allows you to restore tables with auto-incrementing fields whose value is zero. Magento and Drupal require that for proper restoration. NOTE: Per MySQL's documentation: "Storing 0 is not a recommended practice.
ANGIE will normally use INSERT commands to restore the database data. This doesn't work well with certain extensions' data, causing restoration issues. If you get database restoration errors please check this box and click the Next button again.
When checked, ANGIE will try to convert the default collation of your table to Unicode (UTF-8), as suggested by WordPress. This doesn't work on all servers. Check it if you get question marks or broken text instead of international characters.
When checked, ANGIE will try to convert all text fields of restored tables to Unicode (UTF-8). This is a workaround when you cannot use the option above. Please note that if your database collation is anything other than UTF-8 you will have problems in the future, after an extension upgrade adds a new text field.
If enabled and your database server supports UTF8MB4 (UTF-8 Multibyte) it will be used instead of plain old UTF-8. WARNING: Only use if your site was using UTF8MB4 when you backed it up. Uncheck this option if you get broken text after restoring your site!
Should the restoration be immediately stopped if there is an error creating a table, view, function, trigger or stored procedure? If unchecked such errors will be ignored and the restoration will proceed with possible data corruption and / or problems on the restored site.
Should the restoration be immediately stopped if there is an error executing any other database command, such as restoring or deleting data? If unchecked such errors will be ignored and the restoration will proceed with possible data corruption and / or problems on the restored site.
Do not change these settings unless you are requested to do so by our support or you REALLY know what you are doing.
ANGIE breaks up the database restoration process in small processing chunks to avoid server timeouts. This value determines how long each of these chunks will take. You may have to modify this value if your database restoration doesn't complete.
ANGIE can optionally throttle down the rate of the database restoration process for severely misbehaving servers. You can enter the throttle time between processing chunks in milliseconds (1/1000 of a second). For example, in order to add a 5 second throttle time between steps enter 5000 in this box. The default value of 250 should work on most servers.