I am exporting a mySQL database from one server to another. My export file contains all the table definitions, data, structure etc. All tables use the InnoDB engine and the utf8 charset. I am importing with the 'enable foreign key checks' switched off - my export file also has the line 'SET FOREIGN_KEY_CHECKS=0;'.
However, when I import the data, I get the error '#1215 - Cannot add foreign key constraint'
Here is the table definition in the input file:
CREATE TABLE IF NOT EXISTS UserTable (
Index_i int(13) NOT NULL,
UserUUID_vc varchar(36) DEFAULT NULL,
AccountID_i int(13) DEFAULT NULL,
FirstName_vc varchar(30) DEFAULT NULL,
LastName_vc varchar(40) DEFAULT NULL,
Password_vc varchar(255) DEFAULT NULL,
Country_vc varchar(2) DEFAULT NULL,
DateRegistered_dt timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
DateAccountTypeChanged_dt timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
DateAccountStatusChanged_dt timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
DateAcceptedTandC_dt timestamp NOT NULL DEFAULT '0000-00-00 00:00:00'
) ENGINE=InnoDB AUTO_INCREMENT=165 DEFAULT CHARSET=utf8;
It hits this problem before it reads any of the statements that apply constraints such as FK's to the table. In effect it doesn't know if any of these columns are foreign keys or not when it triggers the error message.
Any ideas?
If you're using terminal, login to mysql using your credentials with following command.
mysql -u[your_username] -p[your_password]
Set your mysql foreign key constraint checks to 0 using following command.
SET FOREIGN_KEY_CHECKS = 0;
Import your database using source command like below.
SOURCE /path/to/your/sql/file.sql
And set your mysql foreign key constraint checks back to 1 using following command.
SET FOREIGN_KEY_CHECKS = 1;
Hurrrrrraaaaah. Works like a charm. :)
P.S :- Tested on ubuntu 14.04, 16.04, 18.04
Add it as checkbox - disable foregin key check for this query in phpmyadmin to allow make changes on database
Related
I am trying to backup a database using mysqldump but I got this error:
Trying to backup MySQL database... mysqldump: Couldn't execute 'show create table `transaction_registry`':
Table 'mysql.transaction_registry' doesn't exist in engine (1932)
the problem first were with innodb_index_stats & innodb_table_stats and followed the instructions and worked well but got another problem
I tried from these 1 - 2, but still getting the same error, any ideas?
what I ended doing is like that:
Removed corrupted tables:
rm -rf /var/lib/mysql/mysql/transaction_registry.idb
Recreated the table:
CREATE TABLE transaction_registry (
transaction_id bigint(20) unsigned NOT NULL,
commit_id bigint(20) unsigned NOT NULL,
begin_timestamp timestamp(6) NOT NULL DEFAULT '0000-00-00 00:00:00.000000',
commit_timestamp timestamp(6) NOT NULL DEFAULT '0000-00-00 00:00:00.000000',
isolation_level enum('READ-UNCOMMITTED','READ-COMMITTED','REPEATABLE-READ','SERIALIZABLE') COLLATE utf8_bin NOT NULL, PRIMARY KEY (transaction_id),
UNIQUE KEY commit_id (commit_id), KEY begin_timestamp (begin_timestamp), KEY commit_timestamp (commit_timestamp,transaction_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0 ;
Ref: https://mariadb.com/kb/en/mysqltransaction_registry-table/
Why do I get this weird error when trying to synchronise my model with the mysql database (v5.7.19, workbench v6.3.9)? As you can see from the screenshot, table1_createdOn doesn't even have a default valid, and if i run the generated command with sql query it works:
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 ;
CREATE TABLE IF NOT EXISTS `mydb`.`table1` (
`createdOn` TIMESTAMP NOT NULL,
PRIMARY KEY (`createdOn`))
CREATE TABLE IF NOT EXISTS `mydb`.`table2` (
`createdAt` TIMESTAMP NOT NULL,
`table1_createdOn` TIMESTAMP NOT NULL,
PRIMARY KEY (`table1_createdOn`),
CONSTRAINT `fk_round_table1`
FOREIGN KEY (`table1_createdOn`)
REFERENCES `mydb`.`table1` (`createdOn`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
I am trying to create a table using the script down below and getting the error
Error Code: 1067. Invalid default value for 'LAST_MODIFIED_TS.
In my understanding after 5.6 you could create more than one timestamp column also it is not necessary to provide default values . Another thing is it is not barfing at Created_TS which is just one line before it.
Also the same script works on windows but not on linux ubuntu , the version of mysql running on both of them is 5.7
CREATE TABLE testdb.test (
ID BIGINT NOT NULL AUTO_INCREMENT,
DESCRIPTION VARCHAR(300) NOT NULL,
CREATED_TS TIMESTAMP NOT NULL,
LAST_MODIFIED_TS TIMESTAMP NOT NULL,
PROPERTY_TYPE VARCHAR(1) DEFAULT 'S',
last_modified timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT test_pk PRIMARY KEY
(ID) ) ENGINE=InnoDB ;
Make sure you don't have NO_ZERO_DATE sql_mode variable set (http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date) by running the following query:
show variables like 'sql_mode';
I am trying to alter one of my InnoDB tables.
This is query:
ALTER TABLE `tf5h_assets`
ADD PRIMARY KEY (`id`), ADD UNIQUE KEY `idx_asset_name` (`name`), ADD KEY `idx_lft_rgt` (`lft`,`rgt`), ADD KEY `idx_parent_id` (`parent_id`);
Error is:
#1114 - The table 'tf5h_assets' is full
I do not undesrtand how is it "full" when it's empty table i created from MySQL dump (structure, no data) file.
What's wierd is that i can alter it like this:
ALTER TABLE `tf5h_assets`
ADD PRIMARY KEY (`id`);
ALTER TABLE `tf5h_assets`
ADD UNIQUE KEY `idx_asset_name` (`name`);
ALTER TABLE `tf5h_assets`
ADD KEY `idx_lft_rgt` (`lft`,`rgt`);
ALTER TABLE `tf5h_assets`
ADD KEY `idx_parent_id` (`parent_id`);
and it does not throw that error.
What am i doing wrong?
This ALTER TABLE statements are from structure mysql dump file. Is there a way to split em like i did somehow when structure is exported so i dont have to do it manually?
I googles "table is full" error and this is what i did so far:
1) Checked for disk space - 80+ gigs of free space
2) Added to my.cnf :
innodb_file_per_table = 1
innodb_file_format = barracuda
and rebooted mysql server and created fresh db.
EDIT:
I solved my problem but i have no idea how to solve it for databases that i will not be able to export from Joomla.
Thing is, phpmyadmin is separating table creation from key creation like this:
CREATE TABLE IF NOT EXISTS `tf5h_assets` (
`id` int(10) unsigned NOT NULL COMMENT 'Primary Key',
`parent_id` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set parent.',
`lft` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set lft.',
`rgt` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set rgt.',
`level` int(10) unsigned NOT NULL COMMENT 'The cached level in the nested tree.',
`name` varchar(50) NOT NULL COMMENT 'The unique name for the asset.\n',
`title` varchar(100) NOT NULL COMMENT 'The descriptive title for the asset.',
`rules` varchar(5120) NOT NULL COMMENT 'JSON encoded access control.'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=382 ;
and than later on:
ALTER TABLE `tf5h_assets`
ADD PRIMARY KEY (`id`), ADD UNIQUE KEY `idx_asset_name` (`name`), ADD KEY `idx_lft_rgt` (`lft`,`rgt`), ADD KEY `idx_parent_id` (`parent_id`);
and later on:
ALTER TABLE `tf5h_assets`
MODIFY `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Primary Key',AUTO_INCREMENT=382;
I managed to get my database up and running by using Joomla's backup / restore component (It's Joomla site). I opened up MySQL dump that component created and this is what i found in there:
CREATE TABLE `#__assets`
(`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Primary Key',
`parent_id` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set parent.',
`lft` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set lft.',
`rgt` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set rgt.',
`level` int(10) unsigned NOT NULL COMMENT 'The cached level in the nested tree.',
`name` varchar(50) NOT NULL COMMENT 'The unique name for the asset.\n',
`title` varchar(100) NOT NULL COMMENT 'The descriptive title for the asset.',
`rules` varchar(5120) NOT NULL COMMENT 'JSON encoded access control.',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_asset_name` (`name`),
KEY `idx_lft_rgt` (`lft`,`rgt`),
KEY `idx_parent_id` (`parent_id`) )
ENGINE=InnoDB AUTO_INCREMENT=382 DEFAULT CHARSET=utf8;
Whole process is executed in one run, and it works fine.
Now, i have luck it's Joomla database. But what will i do when database wont be Joomla's? I have no idea. Is there a way to change how phpmyadmin stores dump? Would terminal access to mysql create different mysql dump that would create database in one go instead of using "ALTER"?
Ok so i still don't know what creates this problem except that it has something to do with how phpmyadmin exports databases and reimports them again.
And as i assumed in my original post that i will run into this problem with database that can not be exported trough Joomla component sooner or later, it happened...well...sooner.
Anyway, if you have console access to your mysql server you can deal with this by simply mysql dumping:
mysqldump -p NameOfDatabase > NameOfDumpFile.sql
Download dump file from server and you can import it trough phpmyadmin. It works like a charm. mysqldump creates databases in one query so there is no problem with assigning keys etc.
Why do I get an error of the form:
Error in query: Duplicate entry '10' for key 1
...when doing an INSERT statement like:
INSERT INTO wp_abk_period (pricing_id, apartment_id) VALUES (13, 27)
...with 13 and 27 being valid id-s for existing pricing and apartment rows, and the table is defined as:
CREATE TABLE `wp_abk_period` (
`id` int(11) NOT NULL auto_increment,
`apartment_id` int(11) NOT NULL,
`pricing_id` int(11) NOT NULL,
`type` enum('available','booked','unavailable') collate utf8_unicode_ci default NULL,
`starts` datetime default NULL,
`ends` datetime default NULL,
`recur_type` enum('daily','weekly','monthly','yearly') collate utf8_unicode_ci default NULL,
`recur_every` char(3) collate utf8_unicode_ci default NULL,
`timedate_significance` char(4) collate utf8_unicode_ci default NULL,
`check_in_times` varchar(255) collate utf8_unicode_ci default NULL,
`check_out_times` varchar(255) collate utf8_unicode_ci default NULL,
PRIMARY KEY (`id`),
KEY `fk_period_apartment1_idx` (`apartment_id`),
KEY `fk_period_pricing1_idx` (`pricing_id`),
CONSTRAINT `fk_period_apartment1` FOREIGN KEY (`apartment_id`) REFERENCES `wp_abk_apartment` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT `fk_period_pricing1` FOREIGN KEY (`pricing_id`) REFERENCES `wp_abk_pricing` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
Isn't key 1 id in this case and having it on auto_increment sufficient for being able to not specify it?
Note: If I just provide an unused value for id, like INSERT INTO wp_abk_period (id, pricing_id, apartment_id) VALUES (3333333, 13, 27) it works fine, but then again, it is set as auto_increment so I shouldn't need to do this!
Note 2: OK, this is a complete "twilight zone" moment: so after running the query above with the huge number for id, things started working normally, no more duplicate entry errors. Can someone explain me WTF was MySQL doing to produce this weird behavior?
It could be that your AUTO_INCREMENT value for the table and the actual values in id column have got out of whack.
This might help:
Step 1 - Get Max id from table
select max(id) from wp_abk_period
Step 2 - Align the AUTO_INCREMENT counter on table
ALTER TABLE wp_abk_period AUTO_INCREMENT = <value from step 1 + 100>;
Step 3 - Retry the insert
As for why the AUTO_INCREMENT has got out of whack I don't know. Added auto_increment after data was in the table? Altered the auto_increment value after data was inserted into the table?
Hope it helps.
I had the same problem and here is my solution :
My ID column had a bad parameter. It was Tinyint, and MySql want to write a 128th line.
Sometimes, your problem you think the bigger you have is only a tiny parameter...
Late to the party, but I just ran into this tonight - duplicate key '472817' and the provided answers didn't help.
On a whim I ran:
repair table wp_abk_period
which output
Number of rows changed from 472816 to 472817
Seems like mysql had the row count wrong, and the issue went away.
My environment:
mysql Ver 14.14 Distrib 5.1.73, for Win64 (unknown)
Create table syntax:
CREATE TABLE `env_events` (
`tableId` int(11) NOT NULL AUTO_INCREMENT,
`deviceId` varchar(50) DEFAULT NULL,
`timestamp` int(11) DEFAULT NULL,
`temperature` float DEFAULT NULL,
`humidity` float DEFAULT NULL,
`pressure` float DEFAULT NULL,
`motion` int(11) DEFAULT NULL,
PRIMARY KEY (`tableId`)
) ENGINE=MyISAM AUTO_INCREMENT=528521 DEFAULT CHARSET=latin1
You can check the current value of the auto_increment with the following command:
show table status
Then check the max value of the id and see if it looks right. If not change the auto_increment value of your table.
When debugging this problem check the table name case sensitivity (especially if you run MySql not on Windows).
E.g. if one script uses upper case to 'CREATE TABLE my_table' and another script tries to 'INSERT INTO MY_TABLE'. These 2 tables might have different contents and different file system locations which might lead to the described problem.