tabla solucion puedo incorrectly formed foreign error crear constraint code mysql sql phpmyadmin mysql-error-150

solucion - MySQL: No se puede crear la tabla(errno: 150)



error 150 mysql (30)

por lo general, la falta de correspondencia entre la clave externa y la clave primaria causa el error: 150.

La clave externa debe tener el mismo tipo de datos que la clave principal . Además, si la clave principal no está firmada, entonces la clave externa también debe estar sin firmar .

Estoy intentando importar un archivo .sql y su error al crear tablas.

Aquí está la consulta que falla:

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;

Exporté .sql desde la misma base de datos, dejé caer todas las tablas y ahora estoy intentando importarlo, ¿por qué está fallando?

MySQL: No se puede crear la tabla ''./dbname/data.frm'' (errno: 150)

A veces, MySQL es súper estúpido. Puedo entender la causa de las claves externas ... pero en mi caso, acabo de descartar toda la base de datos, y sigo teniendo el error ... ¿por qué? Es decir, ya no hay ninguna base de datos ... y el usuario de sql que estoy usando no tiene acceso a ningún otro DB en el servidor ... es decir, el servidor está "vacío" para el usuario actual y sigo recibiendo ¿este error? Lo siento, pero supongo que MySQL me está mintiendo ... pero puedo lidiar con eso :) Simplemente agregue estas dos líneas de SQL alrededor de su afirmación fucky:

SET FOREIGN_KEY_CHECKS = 0; # some code that gives you errno: 150 SET FOREIGN_KEY_CHECKS = 1;

Ahora debe ejecutarse el sql ... Si realmente tiene un problema de clave externa, se mostraría en la línea en la que habilitará los controles nuevamente; esto fallará entonces ... pero mi servidor está simplemente tranquilo :)

Asegúrese de que tanto la columna de la clave principal como la columna a la que se hace referencia tengan los mismos tipos de datos y atributos (sin firmar, binarios, zerofill sin firmar, etc.).

Asegúrese de que todas las tablas puedan admitir una clave externa - Motor InnoDB

Cambie los motores de sus tablas, solo innoDB admite claves externas

Corregí el problema haciendo que la variable aceptara null

ALTER TABLE `ajout_norme` CHANGE `type_norme_code` `type_norme_code` VARCHAR( 2 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL

Cree la tabla sin clave externa, luego configure la clave externa por separado.

Creo que todas estas respuestas, aunque correctas, son engañosas para la pregunta.

La respuesta real es esto antes de iniciar una restauración, si está restaurando un archivo de volcado con claves externas:

SET FOREIGN_KEY_CHECKS=0;

porque, naturalmente, la restauración creará algunas restricciones antes incluso de que exista la tabla externa.

De la documentación de restricciones de MySQL - FOREIGN KEY :

Si vuelve a crear una tabla que se descartó, debe tener una definición que se ajuste a las restricciones de clave externa que la hacen referencia. Debe tener los nombres y tipos de columna correctos, y debe tener índices en las claves referenciadas, como se indicó anteriormente. Si no se cumplen, MySQL devuelve el error 1005 y se refiere al error 150 en el mensaje de error, lo que significa que una restricción de clave externa no se formó correctamente. De forma similar, si falla una ALTER TABLE debido al Error 150, esto significa que una definición de clave foránea se formaría incorrectamente para la tabla alterada.

Después de recorrer las respuestas anteriores y experimentar un poco, esta es una forma efectiva de resolver errores de clave externa en MySQL (1005 - error 150).

Para que la clave externa se cree correctamente, todo lo que MySQL solicita es:

  • Todas las claves a las que se hace referencia DEBEN tener índice PRIMARIO o ÚNICO.
  • Hacer referencia a la columna nuevamente DEBE tener un tipo de datos idéntico a la columna Referenciada.

Satisfaga estos requisitos y todo estará bien.

El error 150 significa que tiene un problema con su clave externa. ¿Posiblemente la clave en la tabla extranjera no es del mismo tipo?

En algunos casos, puede encontrar este mensaje de error si hay diferentes motores entre las tablas relacionadas. Por ejemplo, una tabla puede estar utilizando InnoDB mientras que la otra usa MyISAM. Ambos necesitan ser iguales

En la mayoría de los casos, el problema se debe a la diferencia ENGINE. Si el padre es creado por InnoDB, entonces las tablas a las que se hace referencia se supone que serán creadas por MyISAM y viceversa

En mi caso. Tuve problemas con el motor y el juego de caracteres porque mi servidor de alojamiento cambió la configuración y mis nuevas tablas fueron MyISAM, pero mis tablas anteriores son InnoDB. Solo yo cambié.

Error no. 150 significa una falla de restricción de clave externa. Probablemente esté creando esta tabla antes de la tabla de la que depende la clave externa ( keywords tabla). Cree esa tabla primero y debería funcionar bien.

Si no lo hace, elimine la declaración de la clave externa y agréguela después de crear la tabla: obtendrá un mensaje de error más significativo sobre la falla de la restricción específica.

Este error puede ocurrir si dos tablas tienen una referencia, por ejemplo, una tabla es Estudiante y otra tabla es Educación, y queremos que la tabla Educación tenga una referencia de clave externa de la tabla Estudiante. En este caso, el tipo de datos de columna para ambas tablas debe ser el mismo; de lo contrario, generará un error.

Experimenté este error cuando porté la aplicación de Windows a Linux. En Windows, los nombres de las tablas de la base de datos no distinguen entre mayúsculas y minúsculas, y en Linux distinguen entre mayúsculas y minúsculas, probablemente debido a la diferencia del sistema de archivos. Por lo tanto, en la tabla de Windows, Table1 es lo mismo que table1 , y en REFERENCES tanto table1 como Table1 . En Linux, cuando la aplicación utilizaba table1 lugar de Table1 cuando creaba la estructura de la base de datos, vi el error n. ° 150; cuando hice el caso del personaje correcto en las referencias de la Table1 , también comenzó a funcionar en Linux. Por lo tanto, si nada más ayuda, asegúrese de que en REFERENCES utilice el caso de caracteres correcto en el nombre de la tabla cuando está en Linux.

Hay bastantes cosas que pueden causar errno 150, así que para las personas que buscan este tema, aquí está lo que creo que es una lista casi exhaustiva (fuente Causas de Errno 150 ):

Para errno 150 o errno 121, simplemente escribiendo en SHOW ENGINE INNODB STATUS, hay una sección llamada "LETEST FOREIGN KEY ERROR". En virtud de eso, le dará un mensaje de error muy útil, que generalmente le informará de inmediato cuál es el problema. Necesita SÚPER privilegios para ejecutarlo, por lo que si no tiene eso, tendrá que probar los siguientes escenarios.

1) Los tipos de datos no coinciden: los tipos de columnas deben ser iguales

2) Columnas principales no indexadas (o indexadas en orden incorrecto)

3) Las colaciones de columna no coinciden

4) Usar SET NULL en una columna NOT NULL

5) Las colaciones de tablas no coinciden: incluso si las colaciones de columnas coinciden, en algunas versiones de MySQL esto puede ser un problema.

6) La columna principal no existe realmente en la tabla principal. Revise la ortografía (y quizás un espacio al principio o al final de la columna)

7) Uno de los índices en una de las columnas está incompleto o la columna es demasiado larga para un índice completo. Tenga en cuenta que MySQL (a menos que lo modifique) tiene una longitud de clave de columna única máxima de 767 bytes (esto corresponde a una columna varchar (255) UTF)

En caso de que obtenga un errno 121, aquí hay un par de causas:

1) El nombre de restricción que elegiste ya está tomado

2) En algunos sistemas, si hay una diferencia de caso en los nombres de su declaración y tabla. Esto puede morderle si pasa de un servidor a otro que tienen diferentes reglas de manejo de casos.

La columna de la tabla de padres a la que hace referencia desde la tabla secundaria debe ser única. Si no es así, causa un error no 150.

Los tipos de datos deben coincidir exactamente. Si está tratando con tipos varchar, las tablas deben usar la misma intercalación.

Me enfrenté a este tipo de problema al crear DB desde el archivo de texto.

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

Acabo de escribir las líneas anteriores en Create.bat y ejecutar el archivo bat.

Mi error está en el orden de secuencia de ejecución en mis archivos sql. Intenté crear una tabla con la clave principal y también la clave externa. Mientras se ejecuta buscará la tabla de referencia, pero las tablas no están allí. Entonces devolverá ese tipo de error.

Si está creando tablas con clave externa, verifique que las tablas de referencia estén presentes o no. Y también verifique el nombre de las tablas y campos de referencia.

Puede obtener el mensaje de error real ejecutando SHOW ENGINE INNODB STATUS; y luego busca el LATEST FOREIGN KEY ERROR en la salida.

Fuente: respuesta de otro usuario en una pregunta similar

Si la tabla PK se crea en un CHARSET y luego creas la tabla FK en otro CHARSET ... entonces también puedes obtener este error ... Yo también recibí este error, pero después de cambiar el juego de caracteres a charset PK, se ejecutó sin errores

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;

Tal vez this ayude? La definición de la columna de clave principal debe ser exactamente igual a la columna de clave externa.

Tengo el mismo problema al ejecutar una serie de comandos MySQL. El mío ocurre durante la creación de una tabla al hacer referencia a una clave foránea a otra tabla que aún no se creó. Es la secuencia de existencia de la mesa antes de hacer referencia.

La solución: cree primero las tablas padre antes de crear una tabla secundaria que tenga una clave externa.

Tuve el mismo error, luego creé la tabla referenciada primero y luego la mesa referida

por ejemplo, si tiene tablas de empleado y de departamento su asignación de restricción foránea en dept_no en la tabla de empleados, asegúrese de que se crea la tabla de departamento y se han asignado restricciones de clave primaria a dept_no.

esto funcionó para mí ...

Tuve un problema similar al eliminar una base de datos Django mysql con una sola tabla. Pude solucionar el problema volcando la base de datos a un archivo de texto, moviendo la tabla en cuestión hasta el final del archivo usando emacs e importando el archivo de volcado sql modificado en la nueva instancia.

HTH Uwe

Tuve un problema similar, pero el mío fue porque estaba agregando un nuevo campo a una tabla existente que tenía datos, y el nuevo campo hacía referencia a otro campo de la tabla padre y también tenía la definición de NOT NULL y sin ningún VALORES PREDETERMINADOS. - Descubrí que la razón por la que las cosas no funcionaban era porque

  1. Mi nuevo campo necesitaba rellenar automáticamente los campos en blanco con un valor de la tabla padre en cada registro, antes de que se pudiera aplicar la restricción. Cada vez que se aplica la restricción, debe dejar intacta la Integridad de los datos de la tabla. La implementación de la Restricción (clave externa), aunque había algunos registros de la base de datos que no tenían los valores de la tabla padre, significaba que los datos estaban corruptos, por lo que MySQL NUNCA PODRÍA HACER EFECTIVA SU RESTRICCIÓN

Es importante recordar que, en circunstancias normales, si planificó su base de datos con bastante anticipación y se aplicaron restricciones antes de la inserción de datos, se evitaría este escenario en particular.

El enfoque más fácil para evitar este problema es

  • Guarde sus datos de tablas de base de datos
  • Truncar los datos de la tabla (y los artefactos de la tabla, es decir, índices, etc.)
  • Aplica las Restricciones
  • Importa tus datos

Espero que esto ayude a alguien

Un caso límite real es donde ha utilizado una herramienta MySQL, (Sequel Pro en mi caso) para cambiar el nombre de una base de datos. Luego creó una base de datos con el mismo nombre.

Esto mantuvo las restricciones de clave externa al mismo nombre de base de datos, por lo que la base de datos renombrada (por ejemplo, my_db_renamed) tenía restricciones de clave externa en la base de datos recién creada (my_db)

No estoy seguro si esto es un error en Sequel Pro, o si algún caso de uso requiere este comportamiento, pero me costó la mejor parte de una mañana: /

Yo tenía el mismo error. En mi caso, el motivo del error fue que tenía una instrucción ON DELETE SET NULL en la restricción, mientras que el campo en el que puse la restricción en su definición tenía una instrucción NOT NULL. Permitir NULL en el campo resolvió el problema.