У меня есть две таблицы, 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
table2.IDFromTable1
аtable1.ID
?Ответы:
Я столкнулся с той же проблемой с HeidiSQL. Полученная вами ошибка очень загадочна. Моя проблема закончилась тем, что столбец внешнего ключа и столбец ссылки не были одного типа или длины.
Столбец внешнего ключа был,
SMALLINT(5) UNSIGNED
а указанный столбец былINT(10) UNSIGNED
. Как только я сделал их одинакового типа, создание внешнего ключа сработало отлично.источник
У меня была такая же проблема, когда родительская таблица была создана с использованием
MyISAM
engine. Это глупая ошибка, которую я исправил:источник
убедитесь, что столбцы идентичны (одного типа), а если ссылочный столбец - нет
primary_key
, убедитесь, что это такINDEXED
.источник
KEY referencing_column(referencing_column)
ДО определения обоих внешних ключей они оба были добавлены успешно :)Синтаксис для определения внешних ключей очень прост, но для всех, кто с этим справится, тот факт, что внешние ключи должны быть «того же типа», применяется даже к сопоставлению, а не только к типу данных, длине и подписанию битов.
Не то, чтобы вы смешивали параметры сортировки в вашей модели (не так ли?), Но если вы это сделаете, убедитесь, что поля первичного и внешнего ключей имеют одинаковый тип сопоставления в phpmyadmin или Heidi SQL или в любом другом используемом вами формате.
Надеюсь, это сэкономит вам четыре часа проб и ошибок, которые мне стоили.
источник
COLLATE utf8mb4_unicode_ci
была моя (неожиданная) проблема (на компьютере разработчика).У меня была такая же проблема, но я решил ее.
Просто убедитесь, что столбец '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, но я не смог создать внешний ключ. Мне пришлось отключить проверку внешних ключей, чтобы запустить его успешно:
Надеюсь, это кому-нибудь поможет.
источник
Еще одна вероятная причина для отображения этой ошибки. Порядок, в котором я создавал таблицы, был неправильным. Я пытался сослаться на ключ из таблицы, которая еще не была создана.
источник
(Последнее обновление) Даже если имя поля и тип данных одинаковы, но параметры сортировки не совпадают, это также приведет к этой проблеме.
Например
Попробуйте изменить его в
....
Это сработало для меня.
источник
Проверьте движок таблиц, обе таблицы должны быть одинаковыми, что мне очень помогло.
источник
SHOW TABLE STATUS LIKE 'table_name';
У меня были такие же проблемы.
Проблема в том, что ссылочный столбец не является первичным ключом.
Сделайте это первичным ключом, и проблема решена.
источник
Хотя другие ответы весьма полезны, я просто хотел поделиться своим опытом.
Я столкнулся с проблемой, когда удалил таблицу, на которую
id
уже ссылались как на внешний ключ в других таблицах ( с данными ), и попытался воссоздать / импортировать таблицу с некоторыми дополнительными столбцами.Запрос на восстановление (сгенерированный в phpMyAdmin) выглядел следующим образом:
Как вы можете заметить,
PRIMARY KEY
индекс был установлен после создания ( и вставки данных ), которое вызывало проблему.Решение
Решение состояло в том, чтобы добавить
PRIMARY KEY
индекс в запрос определения таблицы для того, наid
который ссылались как на внешний ключ, а также удалить его изALTER TABLE
части, где были установлены индексы:источник
Я потерял на это часы!
ПК в одной таблице был
utf8
в другой былutf8_unicode_ci
!источник
Попробуйте запустить следующее:
источник
У меня была такая же проблема с 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. Итак, вот в чем проблема: таблица, из которой вы хотите сослаться на столбец другой таблицы, отличается либо в случае типа данных, либо с точки зрения размера типа данных.
источник
Убедитесь, что вы указали имя таблицы в правильном регистре (если имена таблиц чувствительны к регистру в вашей базе данных). В моем случае я должен был изменить
в
обратите внимание, что
customer
изменилось наCUSTOMER
.источник
Или вы можете использовать DBDesigner4, который имеет графический интерфейс для создания базы данных и связывания их с помощью FK. Щелкните правой кнопкой мыши по вашей таблице и выберите «Копировать таблицу SQL Create», которая создаст код.
источник
Это старая тема, но я кое-что обнаружил. При создании рабочей среды MySQL он также получает отношения другой таблицы. просто оставь столпы, к которым ты относишься. Очистите другие автоматически добавленные столбцы. Это работает для меня.
источник
Мой случай состоял в том, что у меня была опечатка на упомянутой колонке:
Сообщение об ошибке довольно загадочное, и я перепробовал все - проверка типов столбцов, параметров сортировки, механизмов и т. Д.
Мне потребовалось некоторое время, чтобы заметить опечатку и после исправления все работало нормально:
источник
Я сталкиваюсь с этой проблемой, ошибка возникает, когда вы помещаете первичный ключ в другой тип данных, например:
Таблица 1:
Таблица 2:
тип данных для идентификатора второй таблицы должен быть приращением
источник
Проблема очень проста для решения
Например: у вас есть две таблицы с именами пользователей и сообщений, и вы хотите создать внешний ключ в таблице сообщений, и вы используете phpMyAdmin
1) в посте таблицы добавить новый столбец ( имя : use_id | Тип : как идентификатор в пользователе таблица | Длине : как идентификатор в пользователе таблица | По умолчанию : NULL | Атрибуты : без знака | индекс: INDEX)
2) на вкладке Структура перейдите в представление отношений ( имя ограничения : автоматически устанавливается с помощью phpmyAdmin | имя столбца : выберите идентификатор_пользователя | таблица : пользователи | ключ : идентификатор, ...)
Это было просто решено
источник