Mysql Внешнее ограничение ключа - неправильно сформированная ошибка

Ответ 1

Я столкнулся с этой проблемой с HeidiSQL. Ошибка, которую вы получаете, очень загадочна. Моя проблема закончилась тем, что столбец внешнего ключа и столбец ссылок не имели одинаковый тип или длину.

Столбец внешнего ключа был SMALLINT(5) UNSIGNED, а столбец с ссылкой - INT(10) UNSIGNED. Как только я сделал их одинаковым точным типом, создание внешнего ключа отлично работало.

Ответ 2

У меня была та же проблема, когда родительская таблица была создана с помощью MyISAM engine. Это глупая ошибка, с которой я исправил:

ALTER TABLE parent_table ENGINE=InnoDB;

Ответ 3

убедитесь, что столбцы идентичны (одного типа), а если ссылочный столбец не primary_key, убедитесь, что он INDEXED.

Ответ 4

Синтаксис для определения внешних ключей очень прощает, но для кого-то, кто с этим справляется, тот факт, что внешние ключи должны быть "одного типа", применяется даже к сортировке, а не только по типу и длине данных и подписанию битов.

Не то, чтобы вы смешивали сортировку в своей модели (не так ли?), но если вы это сделаете, убедитесь, что ваши поля первичного и внешнего ключей имеют один и тот же тип сортировки в phpmyadmin или Heidi SQL или что вы используете.

Надеюсь, это избавит вас от четырех часов проб и ошибок, которые мне обошлись.

Ответ 5

Просто для завершения.

Эта ошибка может быть и в том случае, если у вас есть внешний ключ с VARCHAR (..), и кодировка ссылочной таблицы отличается от таблицы, ссылающейся на нее.

например. VARCHAR (50) в таблице Latin1 отличается от VARCHAR (50) в таблице UTF8.

Ответ 6

У меня была такая же проблема, но она была решена.

Просто убедитесь, что идентификатор столбца в 'table1' имеет индекс UNIQUE!

И, конечно, тип, длина идентификаторов столбцов и IDFromTable1 в этих двух таблицах должны быть одинаковыми. Но вы уже знаете об этом.

Ответ 7

Тексты ошибок mysql не очень помогают, в моем случае столбец имел ограничение "не null", поэтому "on delete set null" не разрешено

Ответ 8

если все в порядке, просто добавьте ->unsigned(); в конец foregin key.

если он не работает, проверьте тип данных обоих полей. они должны быть одинаковыми.

Ответ 9

У меня была та же проблема, оба столбца были INT (11) NOT NULL, но я не смог создать внешний ключ. Мне пришлось отключить проверку внешних ключей, чтобы запустить его успешно:

SET FOREIGN_KEY_CHECKS=OFF;
ALTER TABLE ... ADD CONSTRAINT ...
SET FOREIGN_KEY_CHECKS=ON;

Надеюсь, это кому-нибудь поможет.

Ответ 10

Еще одна вероятная причина для отображения этой ошибки. Порядок, в котором я создавал таблицы, был неверным. Я пытался сослаться на ключ из таблицы, которая еще не была создана.

Ответ 11

(Последнее обновление) Даже если имя поля и тип данных совпадают, но параметры сортировки не совпадают, это также приведет к этой проблеме.

Например

TBL NAME | ТИП ДАННЫХ | COLLATION

ActivityID | INT | latin1_general_ci ActivityID | INT | utf8_general_ci

Попробуйте изменить его в

TBL NAME | ТИП ДАННЫХ | COLLATION

ActivityID | INT | latin1_general_ci ActivityID | INT | latin1_general_ci

....

Это сработало для меня.

Ответ 12

Хотя другие ответы весьма полезны, просто хотелось поделиться своим опытом.

Я столкнулся с проблемой, когда удалил таблицу, в которой id уже упоминался как внешний ключ в других таблицах (с данными), и попытался воссоздать/импортировать таблицу с некоторыми дополнительными столбцами.

Запрос на отдых (сгенерированный в phpMyAdmin) выглядит следующим образом:

CREATE TABLE `the_table` (
  `id` int(11) NOT NULL,            /* No PRIMARY KEY index */  
  `name` varchar(255) NOT NULL,
  `name_fa` varchar(255) NOT NULL,
  `name_pa` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

... /* SOME DATA DUMP OPERATION */

ALTER TABLE `the_table`
  ADD PRIMARY KEY (`id`), /* PRIMARY KEY INDEX */
  ADD UNIQUE KEY `uk_acu_donor_name` (`name`);

Как вы можете заметить, индекс PRIMARY KEY был установлен после создания (и ввода данных), который вызывал проблему.

Решение

Решением было добавить индекс PRIMARY KEY в запрос определения таблицы для id, на который ссылался как внешний ключ, а также удалить его из части ALTER TABLE, где были установлены индексы:

CREATE TABLE `the_table` (
  `id` int(11) NOT NULL PRIMARY KEY,            /* <<== PRIMARY KEY INDEX ON CREATION */  
  `name` varchar(255) NOT NULL,
  `name_fa` varchar(255) NOT NULL,
  `name_pa` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Ответ 13

Попробуйте выполнить следующее:

show create table Parent

//and check if type for both tables are the same, like myISAM or innoDB, etc
//Other aspects to check with this error message: the columns used as foreign 
keys must be indexed, they must be of the same type 
(if i.e one is of type smallint(5) and the other of type smallint(6), 
it won't work), and, if they are integers, they should be unsigned.

//or check for charsets
show variables like "character_set_database";
show variables like "collation_database";

//edited: try something like this
ALTER TABLE table2
ADD CONSTRAINT fk_IdTable2
FOREIGN KEY (Table1_Id)
REFERENCES Table1(Table1_Id)
ON UPDATE CASCADE 
ON DELETE CASCADE;

Ответ 14

У меня была такая же проблема с Symfony 2.8.

Я не получил его сначала, потому что не было подобных проблем с длиной int внешних ключей и т.д.

Наконец, мне пришлось сделать следующее в папке проекта. (Перезагрузка сервера не помогла!)

app/console doctrine:cache:clear-metadata app/console doctrine:cache:clear-query app/console doctrine:cache:clear-result

Ответ 15

У меня были те же проблемы.

Проблема заключается в том, что ссылочный столбец не является первичным ключом.

Сделать его первичным ключом и решить проблему.

Ответ 16

спасибо S Doerin:

"Просто для завершения. Эта ошибка может быть и в том случае, если у вас есть внешний ключ с VARCHAR (..), и кодировка ссылочной таблицы отличается от таблицы, ссылающейся на нее. например VARCHAR (50) в таблице Latin1 отличается от VARCHAR (50) в таблице UTF8.

Я решил эту проблему, изменив тип символов таблицы. в создании есть latin1, а правильный - utf8.

добавить следующую строку. DEFAULT CHARACTER SET = utf8;

Ответ 17

У меня возникли проблемы с использованием таблицы Alter, чтобы добавить внешний ключ между двумя таблицами, и то, что помогло мне, заключалось в том, что каждый столбец, который я пытался добавить отношение внешних ключей, был проиндексирован. Для этого в PHP myAdmin: Перейдите в таблицу и нажмите вкладку структуры. Нажмите индексную опцию, чтобы индексировать нужный столбец, как показано на снимке экрана:

Как только я проиндексировал оба столбца, я пытался ссылаться на мои внешние ключи, мне удалось успешно использовать таблицу alter и создать отношение внешнего ключа. Вы увидите, что столбцы индексируются, как показано на следующем скриншоте:

Обратите внимание, как zip_code отображается в обеих таблицах.

Ответ 18

Вам нужно проверить, чтобы оба значения были одинаковыми во всех его свойствах, включительно в "Collation"

Ответ 19

Проверьте механизм таблиц, обе таблицы должны быть одним и тем же движком, что очень помогло мне.

Ответ 20

Я использовал HeidiSQL, и для решения этой проблемы мне пришлось создать индекс в ссылочной таблице со всеми столбцами, на которые ссылаются.

Ответ 21

Я потерял несколько часов для этого!

ПК в одной таблице был utf8 в другой - utf8_unicode_ci !

Ответ 22

У меня была такая же проблема с Laravel 5.1 с помощью схемы построения шаблонов с MariaDB 10.1.

Проблема заключалась в том, что я набрал unigned вместо unsigned (при отсутствии столбца s) при установке столбца.

После исправления ошибки опечатки было исправлено для меня.

Ответ 23

Даже я столкнулся с той же проблемой с mysql и Liquibase.   Так вот в чем проблема:   Таблица, из которой вы хотите ссылаться на столбец другой таблицы, отличается либо в случае типа данных, либо с точки зрения размера типа данных.

Error appears in below scenario:
Scenario 1:
Table A has column id, type=bigint
Table B column referenced_id type varchar(this column gets the value from the id column of Table A.)
Liquibase changeset for table B:

    <changeset id="XXXXXXXXXXX-1" author="xyz">
            <column name="referenced_id" **type="varchar"**>
        </column>
            </changeset>
    <changeSet id="XXXXXXXXXXX-2" author="xyz">
                <addForeignKeyConstraint constraintName="FK_table_A"
                    referencedTableName="A" **baseColumnNames="referenced_id**"
                    referencedColumnNames="id" baseTableName="B" />
    </changeSet>

Table A changeSet:

    <changeSet id="YYYYYYYYYY" author="xyz">
     <column **name="id"** **type="bigint"** autoIncrement="${autoIncrement}">
                    <constraints primaryKey="true" nullable="false"/>
                </column>
    </changeSet>

Solution: 
correct the type of table B to bigint because the referenced table has type bigint.

Scenrario 2:
The type might be correct but the size might not.
e.g. :
Table B : referenced column type="varchar 50"
Table A : base column type ="varchar 255"

Solution change the size of referenced column to that of base table column size.

Ответ 24

Убедитесь, что вы указали имя таблицы в правильном регистре (если имена таблиц чувствительны к регистру в вашей базе данных). В моем случае я должен был изменить

 CONSTRAINT 'FK_PURCHASE_customer_id' FOREIGN KEY ('customer_id') REFERENCES 'customer' ('id') ON UPDATE CASCADE ON DELETE CASCADE

в

 CONSTRAINT 'FK_PURCHASE_customer_id' FOREIGN KEY ('customer_id') REFERENCES 'CUSTOMER' ('id') ON UPDATE CASCADE ON DELETE CASCADE

обратите внимание, что customer изменился на CUSTOMER.

Ответ 25

Или вы можете использовать DBDesigner4, который имеет графический интерфейс для создания вашей базы данных и связывания их с помощью FK. Щелкните правой кнопкой мыши по вашей таблице и выберите "Копировать таблицу SQL Create", которая создаст код.

Ответ 26

Я также новичок в SQL. Я также столкнулся с подобной проблемой. Моя проблема возникает из-за того, что я идентифицирую частичный ключ слабого типа сущности как внешний ключ.

Ответ 27

Я столкнулся с той же проблемой только сейчас. В моем случае все, что мне нужно было сделать, это убедиться, что таблица, на которую я ссылаюсь во внешнем ключе, должна быть создана до текущей таблицы (ранее в коде). Поэтому, если вы ссылаетесь на переменную (x * 5), система должна знать, что такое x (x должен быть объявлен в более ранних строках кода). Это решило мою проблему, надеюсь, это поможет кому-то еще.

Ответ 28

если вы используете phpMyadmin, вы можете пропустить проблему, сняв флажок "Включить проверку внешнего ключа" - тогда вы можете импортировать таблицы, не решая проблему.

уверен, что есть способ пропустить проверки внешнего ключа с помощью mySql CLI

Ответ 29

для тех, кто использует laravel, обратите внимание на ваши миграции, когда вы хотите сделать внешний ключ в

"...references('the_column_name')->on('the_table_name)...",

in_table_name, миграция, которая делает эту таблицу, будет перенесена перед миграцией этой миграции.

чтобы миграции работали должным образом, обратите внимание на их приоритет, измените их приоритет, изменив их имена.