web-dev-qa-db-fra.com

Impossible de définir la relation de clé étrangère

Le problème avec MySQL Workbench est que je n'arrive pas toujours à définir des clés étrangères lors de la création de tables. Je dis parfois parce que ce n'est pas toujours comme ça. Le problème est que lorsque je saisis un FK et que je choisis une table de référence, je ne peux pas choisir une colonne référencée. Je ne peux pas cliquer sur la case à cocher et la liste déroulante est vide. Je ne peux pas vraiment comprendre le problème car je ne vois aucune différence réelle par rapport aux FK qui fonctionnent. J'ai vérifié le type de données, le nom, etc. et ils sont corrects. Je vais fournir un SS pour élaborer. La touche verte (id_hem) fonctionne correctement et les marques rouges ne le sont pas.

Screenshot of WB

24
Sandokan

J'ai eu le même problème et le problème était dans les index de clés étrangères. MySQL Workbench génère parfois des noms trop longs pour les index fk. La correction manuelle aide.

3
Maksym Polshcha

Je sais que c'est vieux, mais les coupables habituels sont Non Null flag et Unsigned. Assurez-vous de les faire correspondre à la colonne de clé étrangère si la colonne référencée les a activées.

37
dwkd

J'ai eu le même problème .. alors j'ai vérifié les deux tableaux .. Le problème était le type, il devrait être apparié dans les deux tableaux.

if in foralda table colonne id_familjer est (INT)
dans la colonne de table fkblixten id_familjer devrait également être (INT) . Si les deux types de données ne correspondent pas, MySQL Workbench ne permet pas de sélectionner la colonne comme clé étrangère. 

8
Chathuranga

Ce peut être aussi à cause de collations différentes. Il suffit de vérifier si ces 2 colonnes ont le même classement.

Dans mon cas on était avec 

Tableau par défaut (utilisation de utf8 general)

l'autre avec 

utf8_unicode_ci

J'ai défini ces 2 colonnes avec utf8_unicode_ci et cela fonctionne.

4
Julien

id_familjer est une clé primaire? réglez.
La colonne référencée n’affiche que la clé primaire de la table familjer.

1
fve

La clé étrangère doit avoir les mêmes constantes similaires à la clé primaire. Vous pouvez ignorer l'IA, la clé primaire. Si la clé primaire a une interface utilisateur, foreign devrait également en avoir une.

UI-> Intermédiaire non signé AI-> Incrémentation automatique

1
ranix

En réponse acceptée Correction manuelle dans le sens suivant: Créez d’abord un index pour la clé de référence dans la table référencée. (vous pouvez le faire dans l'onglet Index disponible dans chaque table). Ensuite, après avoir cliqué sur Appliquer (même sans sélectionner la colonne référencée), modifiez le code de l'application en conséquence.

exemple:

ALTER TABLE `SCHEMA_NAME`.`SECOND_TABLE_NAME` (we are creating foreign key in this second table)
ADD CONSTRAINT `FOREIGN_KEY_NAME`
  FOREIGN KEY (`COLUMN_IN_SECOND_TABLE`)
  REFERENCES `SCHEMA_NAME`.`FIRST_TABLE_NAME` (`COLUMN_IN_FIRST_TABLE`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;
0
L Mandadapu

Dans mon cas, je modifie le "classement" dans toutes les colonnes dans lesquelles je veux définir les clés étrangères. 

Par exemple, le classement de ma colonne FK est 'utf8', je change également ma table de référence en 'utf8' Et ça a résolu mon problème.

J'espère que c'est utile.

0
Rexy Adhi Pratama

Assurez-vous que les types de données sont les mêmes dans les deux tables, comme si l’un disait int et l’autre était int(6), cela ne fonctionnerait pas comme si l’un avait une limite. J'ai eu ce problème et c'est comment je l'ai résolu.

0
FSCockers

Pour ajouter mes deux cents, cela se produit également si vous créez des diagrammes EER dans le même espace de noms de base de données et que deux ou plusieurs diagrammes contiennent une table portant le même nom.

Ainsi, si vous tentez d'établir une relation avec une table (qui existe également dans un autre diagramme portant le même nom), elle apparaîtra deux fois dans la table de référence, les deux font référence au schéma de votre diagramme actuel et ne vous permettront pas une relation.

La solution consiste à renommer la table dans l'autre diagramme.

0
Karl Viiburg