MySQL: impossible de créer une table (numéro d'erreur: 150)
J'essaie d'importer un fichier .sql et son échec lors de la création de tables.
Voici la requête qui échoue:
CREATE TABLE `data` (
`id` int(10) unsigned NOT NULL,
`name` varchar(100) NOT NULL,
`value` varchar(15) NOT NULL,
UNIQUE KEY `id` (`id`,`name`),
CONSTRAINT `data_ibfk_1` FOREIGN KEY (`id`) REFERENCES `keywords` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
J'ai exporté le .sql de la même base de données, j'ai supprimé toutes les tables et maintenant je tente de l'importer, pourquoi échoue-t-il?
MySQL: Impossible de créer la table './dbname/data.frm' (errno: 150)
De la MySQL - FOREIGN KEY Documentation sur les contraintes :
Si vous recréez une table qui a été supprimée, sa définition doit être conforme aux contraintes de la clé étrangère la référant. Il doit avoir les noms et types de colonne corrects, ainsi que des index sur les clés référencées, comme indiqué précédemment. S'ils ne sont pas satisfaits, MySQL renvoie l'erreur 1005 et fait référence à l'erreur 150 dans le message d'erreur, ce qui signifie qu'une contrainte de clé étrangère n'a pas été correctement formée. De même, si ALTER TABLE échoue pour une raison En cas d'erreur 150, cela signifie qu'une définition de clé étrangère serait mal formée pour la table modifiée.
Erreur 150 signifie que vous avez un problème avec votre clé étrangère. Peut-être que la clé sur la table étrangère n'est pas exactement du même type?
Vous pouvez obtenir le message d'erreur en exécutant SHOW ENGINE INNODB STATUS;, puis en recherchant LATEST FOREIGN KEY ERROR dans le résultat.
Source: réponse d'un autre utilisateur à une question similaire
Les types de données doivent correspondre exactement. Si vous utilisez des types varchar, les tables doivent utiliser le même classement.
Je pense que toutes ces réponses, bien que correctes, sont trompeuses.
La réponse réelle est la suivante avant de lancer une restauration, si vous restaurez un fichier de vidage avec des clés étrangères:
SET FOREIGN_KEY_CHECKS=0;
car naturellement, la restauration créera certaines contraintes avant même que la table étrangère n'existe.
Dans certains cas, vous pouvez rencontrer ce message d'erreur s'il existe différents moteurs entre les tables correspondantes. Par exemple, une table peut utiliser InnoDB alors que l'autre utilise MyISAM. Les deux doivent être identiques
Erreur no. 150 signifie une défaillance de contrainte de clé étrangère. Vous créez probablement cette table avant la table dont dépend la clé étrangère (table keywords). Créez cette table en premier et cela devrait fonctionner correctement.
Si ce n'est pas le cas, supprimez l'instruction de clé étrangère et ajoutez-la une fois la table créée: vous obtiendrez un message d'erreur plus significatif concernant l'échec de la contrainte spécifique.
Il y a pas mal de choses qui peuvent causer errno 150, alors pour les personnes cherchant ce sujet, voici ce que je pense être une liste presque exhaustive (source Causes de Errno 150 ):
Pour errno 150 ou 121, saisissez simplement SHOW ENGINE INNODB STATUS, une section intitulée "DERNIÈRE ERREUR DE TOUCHE ÉTRANGÈRE". En dessous, cela vous donnera un message d'erreur très utile, qui vous indiquera généralement tout de suite ce qui ne va pas. Vous devez disposer des privilèges SUPER pour l'exécuter. Si vous ne l'avez pas, vous devrez simplement tester les scénarios suivants.
1) Les types de données ne correspondent pas: les types de colonnes doivent être identiques
2) Colonnes parent non indexées (ou indexées dans le mauvais ordre)
3) Les collations de colonne ne correspondent pas
4) Utilisation de SET NULL sur une colonne NOT NULL
5) Les classements des tableaux ne correspondent pas: même si les classements des colonnes correspondent, certaines versions de MySQL peuvent poser problème.
6) La colonne parent n'existe pas réellement dans la table parent. Vérifiez l'orthographe (et peut-être un espace au début ou à la fin de la colonne)
7) L'un des index de l'une des colonnes est incomplet ou la colonne est trop longue pour un index complet. Notez que MySQL (à moins que vous ne le modifiiez) a une longueur de clé de colonne unique maximale de 767 octets (ceci correspond à une colonne varchar (255) UTF)
Dans le cas où vous obtenez un errno 121, voici quelques causes:
1) Le nom de contrainte que vous avez choisi est déjà pris
2) Sur certains systèmes, s'il existe une différence de casse entre les noms de votre déclaration et de votre table. Cela peut vous piquer si vous passez d'un serveur à un autre avec des règles de traitement différentes.
Parfois, MySQL est tout simplement stupide - je peux comprendre la cause des clés étrangères .. mais dans mon cas, je viens de supprimer la base de données entière et je reçois toujours l'erreur ... pourquoi? je veux dire, il n'y a plus de base de données ... et l'utilisateur SQL que j'utilise n'a accès à aucune autre base de données sur le serveur ... je veux dire, le serveur est "vide" pour l'utilisateur actuel et j'obtiens toujours cette erreur? Désolé mais je suppose que MySQL est en train de me mentir ... mais je peux m'en occuper :) Ajoutez simplement ces deux lignes de code SQL autour de votre fausse déclaration:
SET FOREIGN_KEY_CHECKS = 0;
# some code that gives you errno: 150
SET FOREIGN_KEY_CHECKS = 1;
Maintenant, le sql devrait être exécuté ... Si vous avez vraiment un problème de clé étrangère, il s’affichera par la ligne où vous activerez à nouveau les vérifications - cela échouera alors .. mais mon serveur est tout simplement silencieux :)
J'ai rencontré cette erreur lorsque j'ai porté l'application Windows sous Linux. Sous Windows, les noms de table de base de données ne respectent pas la casse, et sous Linux, ils sont sensibles à la casse, probablement en raison de la différence de système de fichiers. Ainsi, sous Windows, la table Table1 est identique à table1 et, dans REFERENCES, les deux méthodes table1 et Table1 fonctionnent. Sous Linux, lorsque l'application utilisait table1 au lieu de Table1 lorsqu'elle créait la structure de la base de données, je rencontrais l'erreur n ° 150; quand j'ai fait la casse de caractères correcte dans les références Table1, cela a également commencé à fonctionner sous Linux. Ainsi, si rien ne vous aide, assurez-vous que, dans REFERENCES, vous utilisez la casse de caractère correcte dans le nom de la table lorsque vous utilisez Linux.
Après avoir parcouru les réponses ci-dessus et expérimenté un peu, c’est un moyen efficace de résoudre les erreurs de clé étrangère dans MySQL (1005 - erreur 150).
Pour que la clé étrangère soit correctement créée, tout ce que MySQL demande est:
- Toutes les clés référencées DOIVENT avoir un index PRIMARY ou UNIQUE.
- La colonne de référence, à nouveau, DOIT avoir un type de données identique à celui de la colonne référencée.
Satisfaire ces exigences et tout ira bien.
Dans mon cas. J'ai eu des problèmes avec engine et charset parce que les paramètres de modification de mon serveur d'hébergement et mes nouvelles tables étaient MyISAM, mais mes anciennes tables sont InnoDB. Juste j'ai changé.
Changer les moteurs de vos tables, seul innoDB supporte les clés étrangères
J'ai eu le même problème. Il était lié à la colonne Classement et Jeu de caractères . Assurez-vous que Jeu de caractères et Classement doit être identique pour les deux colonnes de deux tableaux. Si vous souhaitez définir une clé étrangère sur cette ... Exemple. Si vous placez une clé étrangère sur la colonne userID de la table userImage faisant référence à la colonne userID de la table users.Le classement doit être identique, à savoir utf8_general_ci et jeu de caractères utf8 pour les deux colonnes de tableaux. Généralement, lorsque vous créez une table, mysql utilise ces deux configurations à partir des paramètres du serveur.
Si la table PK est créée dans unJEU DE CARACTÈRESet que vous créez ensuite une table FK dans un autre CHARSET .. il a été exécuté sans erreurs
create table users
(
------------
-------------
)DEFAULT CHARSET=latin1;
create table Emp
(
---------
---------
---------
FOREIGN KEY (userid) REFERENCES users(id) on update cascade on delete cascade)ENGINE=InnoDB, DEFAULT CHARSET=latin1;
Dans la plupart des cas, le problème provient de la différence de moteur. Si le parent est créé par InnoDB, les tables référencées supposées être créées par MyISAM et vice versa
Cette erreur peut se produire si deux tables ont une référence, par exemple, une table est Étudiant et une autre table est Education et nous voulons que la table Education ait une référence de clé étrangère à la table Student. Dans ce cas, le type de données de colonne pour les deux tables doit être identique, sinon une erreur sera générée.
J'avais un problème similaire, mais le mien était dû au fait que j'ajoutais un nouveau champ à une table existante contenant des données et que le nouveau champ faisait référence à un autre champ de la table parente et comportait également la définition de NOT NULL et sans valeur par défaut. - J'ai découvert que la raison pour laquelle les choses ne fonctionnaient pas était parce que
- Mon nouveau champ devait remplir automatiquement les champs vides avec une valeur de la table parent sur chaque enregistrement, avant que la contrainte ne puisse être appliquée. Chaque fois que la contrainte est appliquée, elle doit préserver l'intégrité des données de la table. Implémentation de la contrainte (clé étrangère), mais certains enregistrements de la base de données ne contenant pas les valeurs de la table parente signifient que les données sont corrompues et que MySQL n'imposera JAMAIS VOTRE CONTRAINT.
Il est important de noter que, dans des circonstances normales, si vous planifiez votre base de données à l’avance et que vous appliquez des contraintes avant l’insertion de données, vous éviterez ce scénario particulier
L’approche la plus simple pour éviter ce problème est de:
- Enregistrez vos données de tables de base de données
- Tronquer les données de la table (et les artefacts de table dans les index, etc.)
- Appliquer les contraintes
- Importez vos données
J'espère que ça aidera quelqu'un
J'ai eu la même erreur. Dans mon cas, la raison de l'erreur était que j'avais une instruction ON DELETE SET NULL dans la contrainte alors que le champ sur lequel je mettais la contrainte dans sa définition avait une instruction NOT NULL. Permettre à NULL sur le terrain a résolu le problème.
Assurez-vous que votre colonne de clé primaire et votre colonne référencée ont les mêmes types de données et attributs (unsigned, binary, unsigned zerofill, etc.).
généralement, la non-concordance entre clé étrangère et clé primaire provoque le erreur: 150.
La clé étrangère doit avoir le même type type de données que la clé primaire. De même, si la clé primaire est unsigned , la clé étrangère doit également être unsigned .
Un vrai cas Edge est l'endroit où vous avez utilisé un outil MySQL, (Sequel Pro dans mon cas) pour renommer une base de données. Puis créé une base de données avec le même nom.
Ceci a gardé les contraintes de clé étrangère sur le même nom de base de données, ainsi la base de données renommée (par exemple, my_db_renamed) avait des contraintes de clé étrangère dans la base de données nouvellement créée (my_db).
Je ne sais pas s'il s'agit d'un bogue dans Sequel Pro, ou si un cas d'utilisation nécessite ce comportement, mais cela m’a coûté cher la majeure partie de la matinée: /
J'ai eu un problème similaire lors du vidage d'une base de données mysql Django avec une seule table. J'ai pu résoudre le problème en vidant la base de données dans un fichier texte, en déplaçant la table en question à la fin du fichier avec emacs et en important le fichier de vidage SQL modifié dans la nouvelle instance.
HTH Uwe
La colonne de la table PARENT à laquelle vous faites référence à partir de la table enfant doit être unique. Si ce n'est pas le cas, provoquez une erreur n ° 150.
J'ai eu le même problème lors de l'exécution d'une série de commandes MySQL. Le mien se produit lors de la création d'une table lors du référencement d'une clé étrangère à une autre table qui n'a pas encore été créée. C'est la séquence de l'existence de la table avant le référencement.
La solution: créez d'abord les tables parent avant de créer une table enfant contenant une clé étrangère.
Assurez-vous que toutes les tables peuvent prendre en charge la clé étrangère - moteur InnoDB
J'ai rencontré ce genre de problème lors de la création de la base de données à partir du fichier texte.
mysql -uroot -padmin < E:\important\sampdb\createdb.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\create_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\create_absence.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\insert_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\insert_absence.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\load_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\load_absence.sql
Je viens d'écrire les lignes ci-dessus dans Create.batet d'exécuter le fichier bat.
Mon erreur est dans l'ordre d'exécution dans mes fichiers SQL. J'ai essayé de créer une table avec une clé primaire et aussi une clé étrangère. Pendant son exécution, il cherchera la table de référence mais les tables ne sont pas là ..__ Donc, il retournera ce genre d'erreur.
Si vous créez des tables avec une clé étrangère, vérifiez la référence les tables étaient présentes ou non. Et vérifiez également le nom de la référence tables et champs.
Peut-être cela aidera? La définition de la colonne de clé primaire doit être identique à celle de la colonne de clé étrangère.
J'ai corrigé le problème en rendant la variable accepter null
ALTER TABLE `ajout_norme`
CHANGE `type_norme_code` `type_norme_code` VARCHAR( 2 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL
J'ai eu la même erreur, alors j'ai créé la table référencée d'abord, puis la table référée
par exemple, si vous avez des tables d'employé et de service affectées étranger contrainte sur dept_no dans la table employee puis assurez-vous que le département table est créée et a attribué des contraintes de clé primaire à dept_no.
cela a fonctionné pour moi ...
Créez la table sans clé étrangère, puis définissez la clé étrangère séparément.
Si vous recréez une table qui a été supprimée, sa définition doit être conforme aux contraintes de la clé étrangère la référant. Il doit avoir les noms et types de colonne corrects, ainsi que des index sur les clés référencées, comme indiqué précédemment. Si ceux-ci ne sont pas satisfaits, MySQL renvoie Erreur 1005 et fait référence à Erreur 150 dans le message d'erreur, ce qui signifie qu'une contrainte de clé étrangère n'a pas été correctement formée. De même, si un ALTER TABLE échoue à cause de l'erreur 150, cela signifie qu'une définition de clé étrangère serait mal formée pour la table modifiée.