Erreur MySQL 1215: impossible d'ajouter une contrainte de clé étrangère

J'essaie de transférer l'ingénierie de mon nouveau schéma sur mon serveur db, mais je ne peux pas comprendre pourquoi j'obtiens cette erreur. J'ai essayé de chercher la réponse ici, mais tout ce que j'ai trouvé a dit de définir le moteur de base de données sur Innodb ou de m'assurer que les clés que j'essaie d'utiliser comme clé étrangère sont des clés primaires dans leurs propres tables . J'ai fait ces deux choses, si je ne me trompe pas. Une autre aide que vous pourriez offrir?

Executing SQL script in server

ERROR: Error 1215: Cannot add foreign key constraint

-- -----------------------------------------------------
-- Table `Alternative_Pathways`.`Clients_has_Staff`
-- -----------------------------------------------------

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Clients_has_Staff` (
  `Clients_Case_Number` INT NOT NULL ,
  `Staff_Emp_ID` INT NOT NULL ,
  PRIMARY KEY (`Clients_Case_Number`, `Staff_Emp_ID`) ,
  INDEX `fk_Clients_has_Staff_Staff1_idx` (`Staff_Emp_ID` ASC) ,
  INDEX `fk_Clients_has_Staff_Clients_idx` (`Clients_Case_Number` ASC) ,
  CONSTRAINT `fk_Clients_has_Staff_Clients`
    FOREIGN KEY (`Clients_Case_Number` )
    REFERENCES `Alternative_Pathways`.`Clients` (`Case_Number` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Clients_has_Staff_Staff1`
    FOREIGN KEY (`Staff_Emp_ID` )
    REFERENCES `Alternative_Pathways`.`Staff` (`Emp_ID` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB

Exécution du script SQL terminée: instructions: 7 réussies, 1 échouée

Voici le SQL pour les tables parentes.

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Clients` (
  `Case_Number` INT NOT NULL ,
  `First_Name` CHAR(10) NULL ,
  `Middle_Name` CHAR(10) NULL ,
  `Last_Name` CHAR(10) NULL ,
  `Address` CHAR(50) NULL ,
  `Phone_Number` INT(10) NULL ,
  PRIMARY KEY (`Case_Number`) )
ENGINE = InnoDB

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Staff` (
  `Emp_ID` INT NOT NULL ,
  `First_Name` CHAR(10) NULL ,
  `Middle_Name` CHAR(10) NULL ,
  `Last_Name` CHAR(10) NULL ,
  PRIMARY KEY (`Emp_ID`) )
ENGINE = InnoDB

Je suppose que Clients.Case_Numberet / ou Staff.Emp_IDne sont pas exactement le même type de données que Clients_has_Staff.Clients_Case_Numberet Clients_has_Staff.Staff_Emp_ID.

Peut-être que les colonnes des tables parentes sont INT UNSIGNED?

Ils doivent être exactement du même type de données dans les deux tables.

Raisons pour lesquelles vous pouvez obtenir une erreur de contrainte de clé étrangère:

1. Vous n'utilisez pas InnoDB comme moteur sur toutes les tables.
2. Vous essayez de référencer une clé inexistante sur la table cible. Assurez-vous qu'il s'agit d'une clé sur l'autre table (il peut s'agir d'une clé primaire ou unique)
3. Les types des colonnes ne sont pas les mêmes (exception est la colonne sur la table de référence peut être nullable).
4. Si le PK / FK est un varchar, assurez-vous que le classement est le même pour les deux.

Mettre à jour:

5. L'une des raisons peut également être que la colonne pour laquelle vous utilisez ON DELETE SET NULLn'est pas définie comme étant nulle. Assurez-vous donc que la colonne est définie par défaut sur null.

Vérifiez-les.

Pour d'autres, la même erreur peut ne pas être toujours due à une incompatibilité de type de colonne, vous pouvez trouver plus d'informations sur une erreur de clé mysql foriegn en exécutant la commande

SHOW ENGINE INNODB STATUS;

vous pouvez trouver une erreur en haut du message imprimé quelque chose comme

Impossible de trouver un index dans la table référencée où les colonnes référencées apparaissent en tant que premières colonnes, ou les types de colonnes dans la table et la table référencée ne correspondent pas pour la contrainte.

L'erreur 1215 est ennuyeuse. La réponse d'Explosion Pill couvre les bases. Vous voulez vous assurer de commencer à partir de là. Cependant, il y a des cas beaucoup plus subtils à surveiller:

Par exemple, lorsque vous essayez de relier clés primaires des tables différentes, assurez - vous de fournir une bonne ON UPDATEet ON DELETEoptions. Par exemple:

...
PRIMARY KEY (`id`),
FOREIGN KEY (`id`) REFERENCES `t` (`other_id`) ON DELETE SET NULL
....

ne volera pas, car les CLÉS PRIMAIRES (telles que id) ne peuvent pas l'être NULL.

Je suis sûr qu'il y a encore plus de problèmes tout aussi subtils lors de l'ajout de ce type de contraintes, c'est pourquoi lorsque vous rencontrez des erreurs de contrainte, assurez-vous toujours que les contraintes et leurs implications ont un sens dans votre contexte actuel. Bonne chance avec votre erreur 1215!

Vérifiez le classement de la table, en utilisant SHOW TABLE STATUSvous pouvez vérifier les informations sur les tables, y compris le classement.

Les deux tables doivent avoir le même classement.

Ça m'est arrivé.

Dans mon cas, j'avais supprimé un tableau en utilisant SET FOREIGN_KEY_CHECKS=0, puis SET FOREIGN_KEY_CHECKS=1après. Quand je suis allé recharger la table, j'ai eu error 1215. Le problème était qu'il y avait une autre table dans la base de données qui avait une clé étrangère à la table que j'avais supprimée et qui se rechargeait. Une partie du processus de rechargement a impliqué la modification d'un type de données pour l'un des champs, ce qui a rendu la clé étrangère de l'autre table non valide, ce qui a déclenché error 1215. J'ai résolu le problème en supprimant puis en rechargeant l'autre table avec le nouveau type de données pour le champ concerné.

J'ai eu la même erreur en essayant d'ajouter un fk. Dans mon cas, le problème est dû au PK de la table FK qui a été marqué comme non signé.

Il y a un piège que j'ai rencontré avec "Erreur 1215: Impossible d'ajouter une contrainte de clé étrangère" lors de l'utilisation de Laravel 4, en particulier avec les générateurs Laravel 4 de JeffreyWay.

Dans Laravel 4, vous pouvez utiliser les générateurs de JeffreyWay pour générer des fichiers de migration pour créer des tables une par une, ce qui signifie que chaque fichier de migration génère une table. Vous devez être conscient du fait que chaque fichier de migration est généré avec un horodatage dans le nom de fichier, ce qui donne un ordre aux fichiers. L'ordre de génération est également l'ordre de l'opération de migration lorsque vous déclenchez la commande CLI Artisan "php artisan migrate". Ainsi, si un fichier demande une contrainte de clé étrangère faisant référence à une clé qui sera, mais pas encore, générée dans un dernier fichier, l'erreur 1215 est déclenchée. Dans ce cas, vous devez ajuster l'ordre de génération des fichiers de migration. Générez de nouveaux fichiers dans le bon ordre, copiez le contenu, puis supprimez les anciens fichiers désordonnés.

j'ai eu le même problème, ma solution:

Avant:

CREATE TABLE EMPRES
( NoFilm smallint NOT NULL

  PRIMARY KEY (NoFilm)

  FOREIGN KEY (NoFilm) REFERENCES cassettes

);

Solution:

CREATE TABLE EMPRES
(NoFilm smallint NOT NULL REFERENCES cassettes,

 PRIMARY KEY (NoFilm)

);

J'espère que c'est de l'aide;)

J'ai eu le même problème.
Je l'ai résolu en faisant ceci:

J'ai créé la ligne suivante dans le
primary key: (id int(11) unsigned NOT NULL AUTO_INCREMENT)

J'ai découvert cette solution après avoir essayé d'importer une table dans mon générateur de schéma. Si cela fonctionne pour vous, faites le moi savoir!

Bonne chance!

Felipe Tércio

Je voulais juste ajouter ce cas aussi pour VARCHAR la relation de clé étrangère. J'ai passé la semaine dernière à essayer de comprendre cela dans MySQL Workbench 8.0 et j'ai finalement pu corriger l'erreur.

Réponse courte: le jeu de caractères et le classement du schéma, de la table, de la colonne, de la table de référence, de la colonne de référence et de toute autre table faisant référence à la table parent doivent correspondre.

Réponse longue: j'avais un type de données ENUM dans ma table. J'ai changé cela en VARCHARet je peux obtenir les valeurs d'une table de référence afin de ne pas avoir à modifier la table parent pour ajouter des options supplémentaires. Cette relation de clé étrangère semblait simple, mais j'ai eu une erreur 1215. La réponse d' Arvind et le lien suivant suggèrent l'utilisation de

SHOW ENGINE INNODB STATUS;

En utilisant cette commande, j'ai obtenu la description détaillée de l'erreur sans aucune information utile supplémentaire

Impossible de trouver un index dans la table référencée où les colonnes référencées apparaissent en tant que premières colonnes, ou les types de colonnes dans la table et la table référencée ne correspondent pas pour la contrainte. Notez que le type de stockage interne ENUM et SET a changé dans les tables créées avec> = InnoDB-4.1.12, et ces colonnes dans les anciennes tables ne peuvent pas être référencées par ces colonnes dans les nouvelles tables. Veuillez vous référer à http://dev.mysql.com/doc/refman/8.0/en/innodb-foreign-key-constraints.html pour la définition correcte de la clé étrangère.

Après quoi j'ai utilisé SET FOREIGN_KEY_CHECKS=0;comme suggéré par Arvind Bharadwaj et le lien ici :

Cela a donné le message d'erreur suivant:

Code d'erreur: 1822. Échec de l'ajout de la contrainte de clé étrangère. Index manquant pour la contrainte

À ce stade, j'ai «rétroconcevoir» le schéma et j'ai pu établir la relation de clé étrangère dans le diagramme EER. Lors de l'ingénierie avancée, j'ai eu l'erreur suivante:

Erreur 1452: impossible d'ajouter ou de mettre à jour une ligne enfant: une contrainte de clé étrangère échoue

Lorsque j'ai `` avancé l'ingénierie '' du diagramme EER vers un nouveau schéma, le script SQL s'est exécuté sans problème. En comparant le SQL généré à partir des tentatives de transfert, j'ai constaté que la différence était le jeu de caractères et le classement. La table parent, la table enfant et les deux colonnes avaient un utf8mb4jeu de caractères et un utf8mb4_0900_ai_ciclassement, cependant, une autre colonne de la table parent a été référencée à l'aide CHARACTER SET = utf8 , COLLATE = utf8_bin ;d'une table enfant différente.

Pour l'ensemble du schéma, j'ai modifié le jeu de caractères et le classement pour toutes les tables et toutes les colonnes comme suit:

CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci;

Cela a finalement résolu mon problème avec l'erreur 1215.

Note latérale: Le classement utf8mb4_general_cifonctionne dans MySQL Workbench 5.0 ou version ultérieure. Le classement utf8mb4_0900_ai_cifonctionne uniquement pour MySQL Workbench 8.0 ou supérieur. Je crois que l'une des raisons pour lesquelles j'ai eu des problèmes avec le jeu de caractères et le classement est due à la mise à niveau de MySQL Workbench vers la version 8.0 entre les deux. Voici un lien qui en dit plus sur cette collation.

Je ne trouve pas cette erreur

CREATE TABLE RATING (

Riv_Id INT(5),
Mov_Id INT(10) DEFAULT 0,
Stars INT(5),
Rating_date DATE, 

PRIMARY KEY (Riv_Id, Mov_Id),

FOREIGN KEY (Riv_Id) REFERENCES REVIEWER(Reviewer_ID)
ON DELETE SET NULL ON UPDATE CASCADE,

FOREIGN KEY (Mov_Id) REFERENCES MOVIE(Movie_ID)
ON DELETE SET DEFAULT ON UPDATE CASCADE
)

Cela se produit également lorsque le type des colonnes n'est pas le même.

Par exemple, si la colonne à laquelle vous faites référence est UNSIGNED INT et la colonne référencée est INT, vous obtenez cette erreur.

Pour MySQL (INNODB) ... obtenez les définitions des colonnes que vous souhaitez lier

SELECT * FROM information_schema.columns WHERE 
TABLE_NAME IN (tb_name','referenced_table_name') AND 
COLUMN_NAME  IN ('col_name','referenced_col_name')\G

comparer et vérifier que les deux définitions de colonne ont

même COLUMN_TYPE (longueur), même COLATION

pourrait être utile de jouer comme

set foreign_key_checks=0;
ALTER TABLE tb_name ADD FOREIGN KEY(col_name) REFERENCES ref_table(ref_column) ON DELETE ...
set foreign_key_checks=1;

Vérifiez la compatibilité des tables. Par exemple, si une table est MyISAMet l'autre est InnoDB, vous pouvez avoir ce problème.

Une autre raison: si vous utilisez ON DELETE SET NULL toutes les colonnes utilisées dans la clé étrangère, vous devez autoriser les valeurs nulles. Quelqu'un d'autre l'a découvert dans cette question .

D'après ma compréhension, ce ne serait pas un problème concernant l'intégrité des données, mais il semble que MySQL ne supporte tout simplement pas cette fonctionnalité (en 5.7).

Lorsque cette erreur se produit car la table référencée utilise le moteur MyISAM, cette réponse fournit un moyen rapide de convertir votre base de données afin que toutes les tables de modèle Django utilisent InnoDB: https://stackoverflow.com/a/15389961/2950621

Il s'agit d'une commande de gestion Django appelée convert_to_innodb.

Wooo je viens de l'avoir! C'était un mélange de nombreuses réponses déjà publiées (innoDB, non signé, etc.). Une chose que je n'ai pas vue ici est cependant: si votre FK pointe sur un PK, assurez-vous que la colonne source a une valeur qui a du sens. Par exemple, si le PK est un mediumint (8), assurez-vous que la colonne source contient également un mediumint (8). Cela faisait partie du problème pour moi.

Pour moi, ce sont les types de colonnes. BigINT! = INT.

Mais cela n'a toujours pas fonctionné.

J'ai donc vérifié les moteurs. Assurez-vous que Table1 = InnoDB et Table = InnoDB

J'ai rencontré cette erreur pour une raison complètement différente. J'ai utilisé MySQL Workbench 6.3 pour créer mon modèle de données (outil génial). J'ai remarqué que lorsque l'ordre des colonnes défini dans la définition de la contrainte de clé étrangère ne correspond pas à la séquence de colonnes de la table, cette erreur est également générée.

Il m'a fallu environ 4 heures pour essayer tout le reste, sauf pour vérifier cela.

Maintenant, tout fonctionne bien et je peux revenir au codage. :-)

lorsque vous essayez de créer une clé étrangère lors de l'utilisation de la migration laravel

comme cet exemple:

table utilisateur

    public function up()
{
    Schema::create('flights', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name');
        $table->TinyInteger('color_id')->unsigned();
        $table->foreign('color_id')->references('id')->on('colors');
        $table->timestamps();
    });
}

tableau des couleurs

    public function up()
{
    Schema::create('flights', function (Blueprint $table) {
        $table->increments('id');
        $table->string('color');
        $table->timestamps();
    });
}

parfois les propriétés ne fonctionnaient pas

[PDOException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint

cette erreur s'est produite car la clé étrangère (type) dans [table utilisateur] est différente de la clé primaire (type) dans [table des couleurs]

Pour résoudre ce problème, vous devez modifier la clé primaire dans [tableau des couleurs]

$table->tinyIncrements('id');

Lorsque vous utilisez la clé primaire $table->Increments('id');

vous devez utiliser Integercomme clé étrangère

    $table-> unsignedInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Lorsque vous utilisez la clé primaire $table->tinyIncrements('id');

vous devez utiliser unsignedTinyIntegercomme clé étrangère

    $table-> unsignedTinyInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Lorsque vous utilisez la clé primaire $table->smallIncrements('id');

vous devez utiliser unsignedSmallIntegercomme clé étrangère

    $table-> unsignedSmallInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Lorsque vous utilisez la clé primaire $table->mediumIncrements('id');

vous devez utiliser unsignedMediumIntegercomme clé étrangère

    $table-> unsignedMediumInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Dans mon cas, j'ai dû désactiver les FOREIGN KEYvérifications car les tables source n'existaient pas.

SET FOREIGN_KEY_CHECKS=0;

Soyez également conscient de l'utilisation des guillemets. J'avais dans un script la déclaration suivante

ALTER TABLE service ADD FOREIGN KEY (create_by) REFERENCES `system_user(id)`;

mais les citations à la fin étaient fausses. Cela aurait dû être:

ALTER TABLE service ADD FOREIGN KEY (create_by) REFERENCES `system_user`(`id`);

MySQL ne donne malheureusement aucun détail sur cette erreur ...

Une autre source de cette erreur est que vous avez 2 ou plusieurs mêmes noms de table qui ont les mêmes noms de clé étrangère. Cela arrive parfois aux personnes qui utilisent des logiciels de modélisation et de conception, comme Mysql Workbench, et génèrent plus tard le script à partir de la conception.

Je sais que je suis TRÈS en retard à la fête mais je veux le mettre ici pour qu'il soit répertorié.

En plus de tous les conseils ci-dessus pour vous assurer que les champs sont définis de manière identique et que les types de table ont également le même classement, assurez-vous que vous ne faites pas l'erreur novice d'essayer de lier des champs où les données du champ CHILD ne sont pas déjà dans le champ PARENT. Si vous avez des données dans le champ ENFANT que vous n'avez pas déjà saisies dans le champ PARENT, cela provoquera cette erreur. C'est dommage que le message d'erreur ne soit pas un peu plus utile.

Si vous n'êtes pas sûr, sauvegardez la table contenant la clé étrangère, supprimez toutes les données, puis essayez de créer la clé étrangère. En cas de succès, vous devez faire quoi!

Bonne chance.

Ceci est une version subtile de ce qui a déjà été dit, mais dans mon cas, j'avais 2 bases de données (foo et bar). J'ai d'abord créé foo et je ne savais pas qu'il faisait référence à une clé étrangère dans bar.baz (qui n'a pas encore été créée). Quand j'ai essayé de créer bar.baz (sans aucune clé étrangère), j'ai continué à recevoir cette erreur. Après avoir regardé autour de moi pendant un moment, j'ai trouvé la clé étrangère dans foo.

Donc, pour faire court, si vous obtenez cette erreur, vous pouvez avoir une clé étrangère préexistante pour la table en cours de création.

Pour moi, l'erreur 1215 s'est produite lors de l'importation d'un fichier de vidage créé par mysqldump, qui crée les tables par ordre alphabétique, ce qui, dans mon cas, a provoqué des clés étrangères pour référencer les tables créées plus tard dans le fichier. (Props à cette page pour le signaler: https://www.percona.com/blog/2017/04/06/dealing-mysql-error-code-1215-cannot-add-foreign-key-constraint/ )

Étant donné que mysqldump commande les tables par ordre alphabétique et que je ne voulais pas changer les noms des tables, j'ai suivi les instructions dans la réponse de JeremyWeir sur cette page , qui indique de mettre set FOREIGN_KEY_CHECKS = 0;en haut du fichier de vidage et de mettre SET FOREIGN_KEY_CHECKS = 1;en bas du fichier de vidage .

Cette solution a fonctionné pour moi.

J'ai donc essayé toutes les corrections ci-dessus et pas de chance. Il se peut que je manque l'erreur dans mes tableaux - je n'ai pas pu trouver la cause et j'ai continué à obtenir l'erreur 1215. J'ai donc utilisé ce correctif.

Dans mon environnement local dans phpMyAdmin, j'ai exporté les données de la table en question. J'ai sélectionné le format CSV. Alors que j'étais encore dans phpMyAdmin avec le tableau sélectionné, j'ai sélectionné "Plus-> Options". Ici, je suis descendu jusqu'à "Copier la table dans (database.table). Sélectionnez" Structure uniquement ". Renommez quelque chose de la table, peut-être ajoutez simplement le mot" copier "à côté du nom de la table actuelle. Cliquez sur" Aller "Cela va créer une nouvelle table. Exportez la nouvelle table et importez-la sur le nouveau serveur ou sur un autre. J'utilise également phpMyAdmin ici également. Une fois importé, remplacez le nom de la table par son nom d'origine. Sélectionnez la nouvelle table, sélectionnez importer. Pour le format, sélectionnez CSV . Décochez "Activer la vérification des clés étrangères". Sélectionnez "Aller". Jusqu'à présent, tout fonctionne bien.

J'ai posté mon correctif sur mon blog .

Même moi, j'ai eu le même problème. Et la faute était avec le marqueur "non signé" dans la table PK du FK

J'ai eu la même erreur une fois. J'ai simplement redémarré le serveur MySQL et corrigé le problème.