mysql La contrainte de clé étrangère est une erreur de forme incorrecte

J’ai deux tables, table1 est la table parente avec un ID colonne et table2 avec une colonne IDFromTable1 (pas le nom réel) quand je mets un FK sur IDFromTable1 à ID dans la table1 IDFromTable1 Foreign key constraint is incorrectly formed error Je voudrais supprimer l’enregistrement de la table 2 si l’enregistrement de table1 est supprimé. Merci pour toute aide

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

Faites-moi savoir si d’autres informations sont nécessaires. Je suis nouveau sur mysql

J’ai rencontré ce même problème avec HeidiSQL. L’erreur que vous recevez est très cryptique. Mon problème a été que la colonne de clé étrangère et la colonne de référence n’étaient pas du même type ou de la même longueur.

La colonne de clé étrangère était SMALLINT(5) UNSIGNED et la colonne référencée était INT(10) UNSIGNED . Une fois que je les ai tous deux faits du même type, la création de la clé étrangère a parfaitement fonctionné.

J’ai eu le même problème lorsque la table parente a été créée en utilisant le moteur MyISAM . C’est une erreur stupide que j’ai corrigé avec:

 ALTER TABLE parent_table ENGINE=InnoDB; 

assurez-vous que les colonnes sont identiques (du même type) et si la colonne de référence n’est pas primary_key , assurez-vous qu’elle est INDEXED .

La syntaxe de définition des clés étrangères est très tolérante, mais pour les autres utilisateurs, le fait que les clés étrangères soient du même type s’applique même au classement, pas seulement au type et à la longueur des données et à la signature des bits.

Non pas que vous mélangez le classement dans votre modèle (est-ce que vous le feriez?) Mais si vous le faites, assurez-vous que vos champs de clé primaire et étrangère sont du même type dans phpmyadmin ou Heidi SQL ou ce que vous utilisez.

J’espère que cela vous épargne les quatre heures d’essais et d’erreurs que cela m’a coûté.

J’ai eu le même problème, mais résolu.

Assurez-vous simplement que la colonne “ID” dans “table1” a un index UNIQUE !

Et bien sûr, le type, la longueur des colonnes ‘ID’ et ‘IDFromTable1’ dans ces deux tables doivent être identiques. Mais vous savez déjà à ce sujet.

Juste pour compléter.

Cette erreur peut également être le cas si vous avez une clé étrangère avec VARCHAR (..) et que le jeu de caractères de la table référencée est différent de la table qui la référence.

Par exemple, VARCHAR (50) dans une table Latin1 est différent de VARCHAR (50) dans une table UTF8.

Les messages d’erreur mysql ne sont pas d’une grande utilité, dans mon cas, la colonne avait une contrainte “non nulle”, donc “on delete set null” n’était pas autorisé

si tout va bien, ajoutez simplement ->unsigned(); à la fin de la foregin key .

Si cela ne fonctionne pas, vérifiez le type de données des deux champs. ils doivent être les mêmes.

Essayez de courir après:

 show create table Parent

 // et vérifier si le type pour les deux tables est le même, comme myISAM ou innoDB, etc.
 // Autres aspects à vérifier avec ce message d'erreur: les colonnes utilisées comme étrangères 
 les clés doivent être indexées, elles doivent être du même type 
 (si c'est un de type smallint (5) et l'autre de type smallint (6), 
 ça ne marchera pas), et si ce sont des entiers, ils doivent être non signés.

 // ou vérifier les jeux de caractères
 afficher des variables comme "character_set_database";
 afficher des variables comme "collation_database";

 // édité: essayez quelque chose comme ça
 ALTER TABLE table2
 AJOUTER UNE CONTRAINTE fk_IdTable2
 Clé étrangère (Table1_Id)
 RÉFÉRENCES Table1 (Table1_Id)
 SUR MISE À JOUR CASCADE 
 SUR SUPPRIMER CASCADE;

J’ai rencontré le même problème avec Symfony 2.8.

Je n’ai pas compris au début, car il n’y avait pas de problèmes similaires avec int longueur des clés étrangères, etc.

Enfin, j’ai dû faire les choses suivantes dans le dossier du projet. (Un redémarrage du serveur n’a pas aidé!)

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

merci S Doerin:

“Juste pour compléter. Cette erreur peut être aussi le cas si vous avez une clé étrangère avec VARCHAR (..) et le jeu de caractères de la table référencée est différent de la table qui le référence. Par exemple, VARCHAR (50) dans une table Latin1 est différent de VARCHAR (50) dans une table UTF8. “

J’ai résolu ce problème en changeant le type de caractères de la table. la création a latin1 et le correct est utf8.

ajoutez la ligne suivante. DEFAUT CHARACTER SET = utf8;

J’ai eu des problèmes en utilisant la table Alter pour append une clé étrangère entre deux tables et la chose qui m’a aidé était de s’assurer que chaque colonne que j’essayais d’append une relation de clé étrangère à était indexée. Pour ce faire dans PHP myAdmin: Allez dans la table et cliquez sur l’onglet Structure. Cliquez sur l’option index pour indexer la colonne souhaitée, comme indiqué dans la capture d’écran:

entrer la description de l'image ici

Une fois que j’ai indexé les deux colonnes que j’essayais de référencer avec mes clés étrangères, j’ai réussi à utiliser la table alter et à créer la relation de clé étrangère. Vous verrez que les colonnes sont indexées comme dans la capture d’écran ci-dessous:

entrer la description de l'image ici

remarquez comment zip_code apparaît dans les deux tables.

J’ai eu les mêmes problèmes.

Le problème est que la colonne de référence n’est pas une clé primaire.

Faites-en une clé primaire et le problème est résolu.

Vous devez vérifier que les deux sont identiques dans toutes ses propriétés, y compris dans “Collation”

Vérifiez le moteur des tables, les deux tables doivent être le même moteur, cela m’a beaucoup aidé.

J’utilisais HeidiSQL et pour résoudre ce problème, je devais créer un index dans la table référencée avec toutes les colonnes référencées.

ajouter un index à la table Heidisql

J’ai eu le même problème, les deux colonnes étaient INT (11) NOT NULL mais je ne pourrais pas créer la clé étrangère. J’ai dû désactiver les vérifications de clés étrangères pour l’exécuter avec succès:

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

J’espère que cela aide quelqu’un.

Une autre cause probable pour l’affichage de cette erreur. L’ordre dans lequel je créais des tables était erroné. J’essayais de référencer une clé dans une table qui n’était pas encore créée.

J’ai eu le même problème avec la migration de Laravel 5.1 avec Schema Builder avec MariaDB 10.1.

Le problème était que j’avais tapé unigned au lieu de unsigned (la lettre s manquait) lors de la définition de la colonne.

Après avoir corrigé l’erreur de faute de frappe a été corrigé pour moi.

Bien que les autres réponses soient très utiles, je voulais simplement partager mon expérience.

J’ai rencontré le problème lorsque j’ai supprimé une table dont l’ id était déjà référencé en tant que clé étrangère dans d’autres tables ( avec des données ) et j’ai essayé de recréer / importer la table avec des colonnes supplémentaires.

La requête pour la récréation (générée dans phpMyAdmin) ressemblait à ceci:

 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`); 

Comme vous pouvez le constater, l’index PRIMARY KEY été défini après la création ( et l’insertion de données ) à l’origine du problème.

Solution

La solution consistait à append l’index PRIMARY KEY sur la définition de la table pour l’ id référencé en tant que clé étrangère, tout en le supprimant de la partie ALTER TABLE où les index étaient définis:

 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; 

Même j’ai rencontré le même problème avec mysql et liquibase. Voici donc le problème: La table à partir de laquelle vous souhaitez référencer une colonne d’une autre table est différente, que ce soit en termes de type de données ou de taille du type de données.

 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:        Table A 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. eg : 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. 

J’ai perdu des heures pour ça!

PK dans une table était utf8 dans autre était utf8_unicode_ci !

Vérifiez que vous avez spécifié le nom de la table dans la casse appropriée (si les noms de table sont sensibles à la casse dans votre firebase database). Dans mon cas je devais changer

  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 

Notez que le customer changé pour CUSTOMER .

Si vous utilisez phpMyadmin, vous pouvez ignorer le problème en décochant la case “Activer les contrôles de clé étrangère” – vous pouvez alors importer les tables sans résoudre le problème.

Assurez-vous qu’il existe un moyen d’ignorer les vérifications de clé étrangère avec la CLI mySql

Ou vous pouvez utiliser DBDesigner4 qui possède une interface graphique pour créer votre firebase database et les relier à l’aide de FK. Cliquez avec le bouton droit sur votre table et sélectionnez «Copier la table SQL Create» qui crée le code.

entrer la description de l'image ici

(Last Resent) Même si le nom du champ et le type de données sont identiques mais que le classement n’est pas le même, cela entraînera également ce problème.

Par exemple

TBL NAME | TYPE DE DONNÉES | COLLATION

ActivityID | INT | latin1_general_ci ActivityID | INT | utf8_general_ci

Essayez de le changer en

TBL NAME | TYPE DE DONNÉES | COLLATION

ActivityID | INT | latin1_general_ci ActivityID | INT | latin1_general_ci

….

Cela a fonctionné pour moi.