I have a query but its showing error #1005 and 150 in details. Some innodb
How to get it right?
CREATE TABLE `iars` ( `id` int(10) unsigned NOT NULL auto_increment,
`SessionId` int(10) unsigned NOT NULL,
`TeacherId` int(10) unsigned NOT NULL,
`courseid` int(4) unsigned NOT NULL,
`semester` int(4) unsigned NOT NULL,
`PaperId` int(4) unsigned NOT NULL,
`groupid` int(4) unsigned NOT NULL,
`Type` varchar(4) default 1,
PRIMARY KEY (`id`),
UNIQUE KEY `Constrint_Index`
(`SessionId`,`TeacherId`,`courseid`,`semester`,`PaperId`,`groupid`),
KEY `FK_tid` (`TeacherId`),
KEY `FK_gid` (`GroupId`),
KEY `FK_pid` (`PaperId`),
CONSTRAINT `FK_gid` FOREIGN KEY (`GroupId`) REFERENCES `groups` (`id`) ON DELETE
CASCADE ON UPDATE CASCADE,
CONSTRAINT `FK_pid` FOREIGN KEY (`PaperId`) REFERENCES `papers` (`p_id`) ON DELETE
CASCADE ON UPDATE CASCADE,
CONSTRAINT `FK_ssessionid` FOREIGN KEY (`SessionId`) REFERENCES `sessions` (`id`) ON
DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT `FK_tid` FOREIGN KEY (`TeacherId`) REFERENCES `teachers` (`id`) ON DELETE
CASCADE ON UPDATE CASCADE )
From the MySQL manual:
You cannot issue DROP TABLE for an InnoDB table that is referenced by a FOREIGN KEY constraint, unless you do SET foreign_key_checks = 0. When you drop a table, the constraints that were defined in its create statement are also dropped.
If you re-create a table that was dropped, it must have a definition that conforms to the foreign key constraints referencing it. It must have the right column names and types, and it must have indexes on the referenced keys, as stated earlier. If these are not satisfied, MySQL returns error number 1005 and refers to error 150 in the error message.
This means one of your other tables is probably referencing a column in iars which you are not re-creating. The solution, then, is to weed through all of your tables (via describe queries) and see where the reference is and either add the referenced column to your CREATE TABLE here, or remove the reference, as appropriate for your schema.
edit a very helpful gem from later on that referenced page:
SHOW ENGINE INNODB STATUS;
reveals loads of good info on the foreign-key error which just occurred. It should point you exactly where you need to look.
Related
I have an odd one. I cannot create a table using the following:
The table Users already exists in the DB, only UserTimeZones is to be added, and it fails.
CREATE TABLE `Users` (
`AccessFailedCount` int(11) NOT NULL,
`EmailConfirmed` bit(1) NOT NULL,
`Id` char(36) NOT NULL,
`NormalizedUserName` varchar(256) DEFAULT NULL,
`NormalizedEmail` varchar(256) DEFAULT NULL,
PRIMARY KEY (`Id`),
UNIQUE KEY `UserNameIndex` (`NormalizedUserName`),
KEY `EmailIndex` (`NormalizedEmail`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `UserTimeZones` (
`Id` char(36) NOT NULL,
`UserId` char(36) NOT NULL,
`TimeZoneOffsetInSeconds` int NOT NULL,
`LastUpdatedAt` datetime(6) NOT NULL,
CONSTRAINT `PK_UserTimeZones` PRIMARY KEY (`Id`),
CONSTRAINT `FK_UserTimeZones_Users_UserId` FOREIGN KEY (`UserId`) REFERENCES `Users` (`Id`) ON DELETE CASCADE
);
SHOW ENGINE INNODB STATUS;
Here is what the status shows:
------------------------ LATEST FOREIGN KEY ERROR
2018-11-09 11:26:44 0x7f832c523700 Error in foreign key constraint of
table fifty/UserTimeZones:
FOREIGN KEY (UserId) REFERENCES Users (Id) ON DELETE CASCADE ):
Cannot find an index in the referenced table where the referenced
columns appear as the first columns, or column types in the table and
the referenced table do not match for constraint.
Note that the internal storage type of ENUM and SET changed in tables
created with >= InnoDB-4.1.12, and such columns in old tables cannot
be referenced by such columns in new tables.
Please refer to
http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html
for correct foreign key definition.
So I have the classic "Cannot add foreign key constraint".
What I have tried:
Placing the Users.Id column as first column : doesn't change anything
The column types are the same, the engines too...
Applying the migration without data in the DB -> it works
Running the script in a DB without data -> still doesn't work...
What is the problem?
Not sure it matters but I use entity framework core.
https://dev.mysql.com/doc/refman/8.0/en/innodb-foreign-key-constraints.html
Foreign key definitions for InnoDB tables are subject to the following
conditions:
InnoDB permits a foreign key to reference any index column or group of
columns. However, in the referenced table, there must be an index
where the referenced columns are listed as the first columns in the
same order.
But oddly the index seems to be needed on the referencing table:
https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html#foreign-keys-examples
So try adding an index on your table
CREATE TABLE `UserTimeZones` (
`Id` char(36) NOT NULL,
`UserId` char(36) NOT NULL,
`TimeZoneOffsetInSeconds` int NOT NULL,
`LastUpdatedAt` datetime(6) NOT NULL,
CONSTRAINT `PK_UserTimeZones` PRIMARY KEY (`Id`),
INDEX userid_ind (UserId),
CONSTRAINT `FK_UserTimeZones_Users_UserId` FOREIGN KEY (`UserId`) REFERENCES `Users` (`Id`) ON DELETE CASCADE
);
Note: this is what the error message says.
Hello my appologies for asking aid but i'm having a little issue in a database adding references
so i got a table
CREATE TABLE `kooien` (
`kooiid` INT(11) NOT NULL AUTO_INCREMENT,
`kooidlistppg` INT(11) NULL,
`quarantaine` BIT(1) NOT NULL,
`idvogelsoort` INT(11) NULL DEFAULT NULL,
`idvogelondersoort` INT(11) NULL DEFAULT NULL,
`vasteoflossekooie` BIT(1) NOT NULL,
`bezetofniet` BIT(1) NOT NULL,
`idlistsponsor` INT(11) NULL DEFAULT NULL,
PRIMARY KEY (`kooiid`),
INDEX `idvogelsoort` (`idvogelsoort`),
INDEX `idvogelondersoort` (`idvogelondersoort`),
INDEX `kooien_ibfk_4_idx` (`idlistsponsor`),
CONSTRAINT `kooien_ibfk_2` FOREIGN KEY (`idvogelsoort`) REFERENCES `vogelsoort` (`id`),
CONSTRAINT `kooien_ibfk_3` FOREIGN KEY (`idvogelondersoort`) REFERENCES `ondersoort` (`id`),
CONSTRAINT `kooien_ibfk_4` FOREIGN KEY (`idlistsponsor`) REFERENCES `personen` (`id`),
CONSTRAINT `FK_kooien_kooientoppg` FOREIGN KEY (`kooidlistppg`) REFERENCES `kooientoppg` (`id`))
COLLATE='utf8_general_ci'
ENGINE=InnoDB
Which appears like
kooiid|kooidlistppg|quarantaine|idvogelsoort|idvogelondersoort|Vasteoflossekooien|bezetofniet|lijstlist sponsor
Now my problem is making kooidlistppg references to kooidlistppg(id)
i do so with this query
ALTER TABLE `kooien`
DROP INDEX `FK_kooien_kooientoppg`,
ADD CONSTRAINT `FK_kooien_kooientoppg` FOREIGN KEY (`kooidlistppg`) REFERENCES `kooientoppg` (`id`);
/* SQL Fout (1215): Cannot add foreign key constraint */
ill add the create query for the table
CREATE TABLE `kooientoppg` (
`id` INT(11) NOT NULL,
`idpapegaaien` INT(11) NULL DEFAULT NULL
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
please know that its lack of a primary key is to convert a list to a mysql database
As explained in the MySQL manual, details of FOREIGN KEY errors with InnoDB can be checked with the following SQL command:
SHOW ENGINE INNODB STATUS
For example:
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2017-01-22 23:43:46 0x7fc9fc0f1700 Error in foreign key constraint of table test/kooien:
FOREIGN KEY (`kooidlistppg`) REFERENCES `kooientoppg` (`id`))
COLLATE='utf8_general_ci'
ENGINE=InnoDB:
Cannot find an index in the referenced table where the
referenced columns appear as the first columns, or column types
in the table and the referenced table do not match for constraint.
Note that the internal storage type of ENUM and SET changed in
tables created with >= InnoDB-4.1.12, and such columns in old tables
cannot be referenced by such columns in new tables.
Please refer to http://dev.mysql.com/doc/refman/8.0/en/innodb-foreign-key-constraints.html for correct foreign key definition.
As far as I can tell, adding an index to the referenced column would help:
ALTER TABLE kooientoppg ADD INDEX id_idx (id);
I have two tables -
CREATE TABLE `FOO` (
`user_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
/*Nothing to see here*/
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=380 DEFAULT CHARSET=latin1;
CREATE TABLE `BAR` (
`ID` int(11) unsigned NOT NULL,
`UserID` int(11) unsigned DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `VSK_UserID_Index` (`UserID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
I am attempting create a foreign key constraint on BAR.UserID referencing users.user_id -
ALTER TABLE `FOO`.`BAR`
ADD CONSTRAINT `BAR_UserID_FKey`
FOREIGN KEY (`UserID`)
REFERENCES `FOO`.`users` (`user_id`)
ON DELETE CASCADE
ON UPDATE CASCADE;
I keep getting this error -
Operation failed: There was an error while applying the SQL script to the database.
Error 1452: Cannot add or update a child row: a foreign key constraint fails
Both of these tables have data in them - could this be the reason why this is happening, or is there something wrong with how the tables are being created?
Is there something I need to alter on one of these tables to make this work?
The data already in one of the tables (in particular, `FOO`.`BAR`, since that is the one you're adding a constraint to) is not consistent with the data in `FOO`.`users` (`user_id`).
You must ensure that the values un the `FOO`.`BAR`.`UserID` column all exist in `FOO`.`users` (`user_id`). There may be null values or other values that do not exist in the other column.
I have this error when I try to create a table: Can't create table users_groups (errno: 150)
My script:
CREATE TABLE `users_groups` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(11) unsigned NOT NULL,
`group_id` mediumint(8) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `fk_users_groups_users1_idx` (`user_id`),
KEY `fk_users_groups_groups1_idx` (`group_id`),
CONSTRAINT `uc_users_groups` UNIQUE (`user_id`, `group_id`),
CONSTRAINT `fk_users_groups_users1` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION,
CONSTRAINT `fk_users_groups_groups1` FOREIGN KEY (`group_id`) REFERENCES `groups` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Error 150 is related to the definition of foreign keys.
You did not mention the MySQL version, but here are a few things to check:
tables should exist, and their storage engine should all be InnoDB
referenced columns should exist
indexes on referenced columns should exist in the referenced tables
definition of the index (including column order) should match the definition of the foreign key
data types of referenced columns should be identical (including length, null values, etc ...)
The documentation of MySQL says it is possible to use the "SHOW ENGINE INNODB STATUS" command just after error 150 to get more information about the error itself. I suggest you try it. In the output, search for the 'LATEST FOREIGN KEY ERROR' section.
I was migrating mysql database to postgres and stumbled across the following block in DDL (Note: This is what I got from mysqldump):
CREATE TABLE `catalog_property_value` (
`id` int(10) unsigned NOT NULL,
`property_id` int(10) unsigned NOT NULL,
`sort` int(10) unsigned NOT NULL,
`value_number` decimal(15,5) DEFAULT NULL,
`value_string` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`,`sort`),
KEY `FK_catalog_property_value` (`property_id`),
KEY `NewIndex1` (`id`),
CONSTRAINT `FK_catalog_property_value` FOREIGN KEY (`property_id`) REFERENCES `catalog_property` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SET character_set_client = #saved_cs_client;
CREATE TABLE `catalog_realty_property_value_link` (
`realty_id` int(10) unsigned NOT NULL,
`property_id` int(10) unsigned NOT NULL,
`value_id` int(10) unsigned NOT NULL,
`dt_is_denormalized` tinyint(1) unsigned NOT NULL,
PRIMARY KEY (`realty_id`,`property_id`,`value_id`),
KEY `FK_catalog_realty_property_value_link_property` (`property_id`),
KEY `FK_catalog_realty_property_value_link_value` (`value_id`),
CONSTRAINT `FK_catalog_realty_property_value_link_property` FOREIGN KEY (`property_id`) REFERENCES `catalog_property` (`id`) ON DELETE CASCADE,
CONSTRAINT `FK_catalog_realty_property_value_link_realty` FOREIGN KEY (`realty_id`) REFERENCES `catalog_realty` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT `FK_catalog_realty_property_value_link_value` FOREIGN KEY (`value_id`) REFERENCES `catalog_property_value` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Now, what I see here is that the only unique key in the first table is combination of (id, sort):
PRIMARY KEY (`id`,`sort`),
however, the second table has a reference to the first on by only id column, which is not unique!
CONSTRAINT `FK_catalog_realty_property_value_link_value` FOREIGN KEY (`value_id`) REFERENCES `catalog_property_value` (`id`) ON DELETE CASCADE
So, what did I get wrong here? How is that possible?
From the manual:
Deviation from SQL standards: A
FOREIGN KEY constraint that references
a non-UNIQUE key is not standard SQL.
It is an InnoDB extension to standard
SQL.
So it looks like InnoDB allows non-unique indexes as candidates for foreign key references. Elsewhere the manual states that you can reference a subset of columns in the referenced index as long as the referenced columns are listed first and in the same order as the primary key.
Therefore, this definition is legal in InnoDB, although it's not standard SQL and leaves me, at least, a little confused as to the original designer's intentions.
Manual page here.
This weird behavior of FK's in innoDB is described in the manual.
The handling of foreign key references to nonunique keys or keys
that contain NULL values is not well
defined for operations such as UPDATE
or DELETE CASCADE. You are advised to
use foreign keys that reference only
UNIQUE and NOT NULL keys.
PostgreSQL doesn't accept this construction, the foreign key has to point to a unique key.
This is perfectly legal according to wikipedia:
The columns in the referencing table
must be the primary key or other
candidate key in the referenced table.
The most likely answer is that id really is unique in the catalog_propery_value table, but that the author declared the PK to be the superkey (id, sort) for reasons unknown, possibly having to do with indexing, rather than enforcing uniqueness.