mysql Неправильно сформированное ограничение внешнего ключа

У меня есть две таблицы, table1это родительская таблица с колонкой IDи table2с колонной IDFromTable1(не фактическое имя) , когда я ставлю на FK , IDFromTable1чтобы IDв table1я получаю ошибку Foreign key constraint is incorrectly formed error. Я хотел бы удалить запись таблицы 2, если table1запись удаляется. Спасибо за любую помощь

ALTER TABLE `table2`  
   ADD CONSTRAINT `FK1` 
      FOREIGN KEY (`IDFromTable1`) REFERENCES `table1` (`ID`) 
      ON UPDATE CASCADE 
      ON DELETE CASCADE;

Дайте мне знать, нужна ли какая-либо другая информация. Я новичок в MySQL

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

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

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

ALTER TABLE parent_table ENGINE=InnoDB;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например

    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

....

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

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

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

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

Сделайте это первичным ключом, и проблема решена.

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

Я столкнулся с проблемой, когда удалил таблицу, на которую 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;

Я потерял на это часы!

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

Попробуйте запустить следующее:

показать создать таблицу Parent

// и проверяем, одинаковый ли тип для обеих таблиц, например myISAM или innoDB и т. д.
// Другие аспекты, чтобы проверить с этим сообщением об ошибке: столбцы, используемые как иностранные 
ключи должны быть проиндексированы, они должны быть одного типа 
(если, например, один имеет тип smallint (5), а другой - тип smallint (6), 
это не сработает), и, если они целые, они должны быть без знака.

// или проверить кодировки
показать переменные, такие как "character_set_database";
показать переменные типа "collation_database";

// отредактировано: попробуйте что-то вроде этого
ALTER TABLE table2
ADD CONSTRAINT fk_IdTable2
ИНОСТРАННЫЙ КЛЮЧ (Table1_Id)
ССЫЛКИ Table1 (Table1_Id)
ОБ ОБНОВЛЕНИИ КАСКАДА 
НА УДАЛЕННОМ КАСКАДЕ;

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

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

Наконец я должен был сделать следующее в папке проекта. (Перезагрузка сервера не помогла!)

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

спасибо S Doerin:

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

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

добавить следующую строку. Набор символов по умолчанию = utf8;

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

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

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

Вам нужно проверить, чтобы оба были одинаковыми по всем своим свойствам, в том числе в «Сличении»

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

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

У меня была та же проблема с Laravel 5.1 миграцией Schema Builder с MariaDB 10.1.

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

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

Даже я столкнулся с той же проблемой с 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's column size.

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

 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.

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

Это старая тема, но я кое-что обнаружил. При создании рабочей среды MySQL он также получает отношения другой таблицы. просто оставь столпы, к которым ты относишься. Очистите другие автоматически добавленные столбцы. Это работает для меня.

Мой случай состоял в том, что у меня была опечатка на упомянутой колонке:

MariaDB [blog]> alter table t_user add FOREIGN KEY ( country_code ) REFERENCES t_country ( coutry_code );
ERROR 1005 (HY000): Can't create table `blog`.`t_user` (errno: 150 "Foreign key constraint is incorrectly formed")

Сообщение об ошибке довольно загадочное, и я перепробовал все - проверка типов столбцов, параметров сортировки, механизмов и т. Д.

Мне потребовалось некоторое время, чтобы заметить опечатку и после исправления все работало нормально:

MariaDB [blog]> alter table t_user add FOREIGN KEY ( country_code ) REFERENCES t_country ( country_code );
Query OK, 2 rows affected (0.039 sec)              
Records: 2  Duplicates: 0  Warnings: 0

Я сталкиваюсь с этой проблемой, ошибка возникает, когда вы помещаете первичный ключ в другой тип данных, например:

Таблица 1:

 Schema::create('products', function (Blueprint $table) {
            $table->increments('id');
            $table->string('product_name');
        });

Таблица 2:

Schema::create('brands', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('brand_name');
        });

тип данных для идентификатора второй таблицы должен быть приращением

Проблема очень проста для решения

Например: у вас есть две таблицы с именами пользователей и сообщений, и вы хотите создать внешний ключ в таблице сообщений, и вы используете phpMyAdmin

1) в посте таблицы добавить новый столбец ( имя : use_id | Тип : как идентификатор в пользователе таблица | Длине : как идентификатор в пользователе таблица | По умолчанию : NULL | Атрибуты : без знака | индекс: INDEX)

2) на вкладке Структура перейдите в представление отношений ( имя ограничения : автоматически устанавливается с помощью phpmyAdmin | имя столбца : выберите идентификатор_пользователя | таблица : пользователи | ключ : идентификатор, ...)

Это было просто решено

Джавад Мосави Иран / Урмия