mysql - tipos - no se puede agregar o actualizar una fila secundaria falla una restricción de clave externa
La restricción de clave externa mysql es un error incorrectamente formado (26)
¡Perdí durante horas por eso!
PK en una tabla era utf8 en otra era utf8_unicode_ci !
Tengo dos tablas, table1 es la tabla padre con un ID columna y table2 con una columna IDFromTable1 (no el nombre real) cuando pongo un FK en IDFromTable1 a ID en table1 obtengo el error. Foreign key constraint is incorrectly formed error . Me gustaría eliminar el registro de la tabla 2 si el registro de la tabla 1 se elimina. Gracias por cualquier ayuda
ALTER TABLE `table2`
ADD CONSTRAINT `FK1`
FOREIGN KEY (`IDFromTable1`) REFERENCES `table1` (`ID`)
ON UPDATE CASCADE
ON DELETE CASCADE;
Avíseme si se necesita alguna otra información. Soy nuevo en mysql
(Último resentimiento) Incluso si el nombre del campo y el tipo de datos son los mismos, pero la intercalación no es la misma, también dará como resultado ese problema.
Por ejemplo
TBL NOMBRE | TIPO DE DATOS | COLACIÓN
ActivityID | INT | latin1_general_ci ActivityID | INT | utf8_general_ci
Intente cambiarlo a
TBL NOMBRE | TIPO DE DATOS | COLACIÓN
ActivityID | INT | latin1_general_ci ActivityID | INT | latin1_general_ci
....
Esto funcionó para mí.
Aunque las otras respuestas son bastante útiles, solo quería compartir mi experiencia también.
Me enfrenté al problema cuando eliminé una tabla cuyo id ya estaba siendo referenciado como clave externa en otras tablas ( con datos ) y traté de volver a crear / importar la tabla con algunas columnas adicionales.
La consulta de recreación (generada en phpMyAdmin) se veía como la siguiente:
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`);
Como puede observar, el índice PRIMARY KEY se configuró después de la creación ( y la inserción de datos ) que causaba el problema.
Solución
La solución consistía en agregar el índice PRIMARY KEY en la consulta de definición de tabla para el id que se hacía referencia como clave foránea, y al mismo tiempo eliminarlo de la parte ALTER TABLE donde se estaban estableciendo los índices:
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;
Comprueba el motor de tablas, ambas tablas tienen que ser el mismo motor, eso me ayudó mucho.
Compruebe que ha especificado el nombre de la tabla en el caso adecuado (si los nombres de las tablas distinguen entre mayúsculas y minúsculas en su base de datos). En mi caso tuve que cambiar
CONSTRAINT `FK_PURCHASE_customer_id` FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) ON UPDATE CASCADE ON DELETE CASCADE
a
CONSTRAINT `FK_PURCHASE_customer_id` FOREIGN KEY (`customer_id`) REFERENCES `CUSTOMER` (`id`) ON UPDATE CASCADE ON DELETE CASCADE
tenga en cuenta que el customer cambió a CUSTOMER .
Incluso me encontré con el mismo problema con mysql y liquibase. Así que este es el problema: la tabla desde la que desea hacer referencia a una columna de otra tabla es diferente en el caso del tipo de datos o en términos de tamaño del tipo de datos.
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:
<changeset id="XXXXXXXXXXX-1" author="xyz">
<column name="referenced_id" **type="varchar"**>
</column>
</changeset>
<changeSet id="XXXXXXXXXXX-2" author="xyz">
<addForeignKeyConstraint constraintName="FK_table_A"
referencedTableName="A" **baseColumnNames="referenced_id**"
referencedColumnNames="id" baseTableName="B" />
</changeSet>
Table A changeSet:
<changeSet id="YYYYYYYYYY" author="xyz">
<column **name="id"** **type="bigint"** autoIncrement="${autoIncrement}">
<constraints primaryKey="true" nullable="false"/>
</column>
</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.
e.g. :
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.
Intenta ejecutar lo siguiente:
show create table Parent //and check if type for both tables are the same, like myISAM or innoDB, etc //Other aspects to check with this error message: the columns used as foreign keys must be indexed, they must be of the same type (if i.e one is of type smallint(5) and the other of type smallint(6), it won''t work), and, if they are integers, they should be unsigned. //or check for charsets show variables like "character_set_database"; show variables like "collation_database"; //edited: try something like this ALTER TABLE table2 ADD CONSTRAINT fk_IdTable2 FOREIGN KEY (Table1_Id) REFERENCES Table1(Table1_Id) ON UPDATE CASCADE ON DELETE CASCADE;
La sintaxis para definir claves externas es muy indulgente, pero para cualquier persona que se tropiece con esto, el hecho de que las claves foráneas deben ser "del mismo tipo" se aplica incluso a la intercalación, no solo al tipo y longitud de datos y a la firma de bits.
No es que mezclarías la intercalación en tu modelo (¿verdad?), Pero si lo haces, asegúrate de que los campos de clave principal y externa sean del mismo tipo de intercalación en phpmyadmin o Heidi SQL o lo que sea que uses.
Espero que esto te ahorre las cuatro horas de prueba y error que me costó.
Los textos de error de mysql no ayudan mucho, en mi caso, la columna tenía una restricción "no nula", por lo que no se permitía el "en el conjunto de eliminación nulo"
Me encontré con este mismo problema con HeidiSQL. El error que recibes es muy críptico. Mi problema terminó siendo que la columna de clave externa y la columna de referencia no eran del mismo tipo o longitud.
La columna de clave externa era SMALLINT(5) UNSIGNED y la columna a la que se hace referencia era INT(10) UNSIGNED . Una vez que hice que ambos fueran del mismo tipo exacto, la creación de la clave externa funcionó perfectamente.
Necesita verificar que ambos sean iguales en todas sus propiedades, inclusive en "Colación"
Si usa phpMyadmin, puede omitir el problema desmarcando "Habilitar comprobaciones de claves externas"; luego puede importar las tablas sin solucionar el problema.
Seguro que hay una forma de omitir las comprobaciones de claves externas con mySql CLI
Solo por completar.
Este error también podría ser el caso si tiene una clave externa con VARCHAR (..) y el conjunto de caracteres de la tabla referenciada es diferente de la tabla que hace referencia a él.
por ejemplo, VARCHAR (50) en una tabla Latin1 es diferente de VARCHAR (50) en una tabla UTF8.
Tenía los mismos problemas.
El problema es que la columna de referencia no es una clave principal.
Conviértalo en la clave principal y solucione el problema.
Tuve el mismo problema con Laravel 5.1 Schema Builder de migración con MariaDB 10.1.
El problema era que había escrito sin unigned lugar de unsigned (faltaba s letra) mientras configuraba la columna.
Después de corregir el error de escritura, se solucionó el problema.
Tuve el mismo problema con Symfony 2.8.
No lo obtuve al principio, porque no hubo problemas similares con la longitud int de claves externas, etc.
Finalmente tuve que hacer lo siguiente en la carpeta del proyecto. (¡Un reinicio del servidor no ayudó!)
app/console doctrine:cache:clear-metadata app/console doctrine:cache:clear-query app/console doctrine:cache:clear-result
Tuve el mismo problema cuando la tabla primaria se creó usando el motor MyISAM . Es un error tonto, que arreglé con:
ALTER TABLE parent_table ENGINE=InnoDB;
Tuve el mismo problema, ambas columnas eran INT (11) NOT NULL pero no pude crear la clave foránea. Tuve que desactivar las claves externas para ejecutarlo con éxito:
SET FOREIGN_KEY_CHECK=OFF;
ALTER TABLE ... ADD CONSTRAINT ...
SET FOREIGN_KEY_CHECK=ON;
Espero que esto ayude a alguien.
Tuve el mismo problema, pero lo resolvió.
¡Solo asegúrese de que la columna ''ID'' en ''table1'' tenga un índice ÚNICO !
Y, por supuesto, el tipo, la longitud de las columnas ''ID'' e ''IDFromTable1'' en estas dos tablas tienen que ser las mismas. Pero ya sabes sobre esto.
Tuve problemas al usar la tabla Alter para agregar una clave foránea entre dos tablas y lo que me ayudó fue asegurarme de que cada columna a la que estaba tratando de agregar una relación de clave externa estuviera indexada. Para hacer esto en PHP myAdmin: Vaya a la tabla y haga clic en la pestaña de estructura. Haga clic en la opción de índice para indexar la columna deseada como se muestra en la captura de pantalla:
Una vez que indexé ambas columnas que estaba tratando de referenciar con mis claves externas, pude usar con éxito la tabla alter y crear la relación de clave externa. Verá que las columnas están indexadas como en la captura de pantalla siguiente:
observe cómo zip_code aparece en ambas tablas.
Una causa más probable para la visualización de este error. El orden en el que estaba creando tablas estaba mal. Intentaba hacer referencia a una clave de una tabla que aún no se había creado.
asegúrese de que las columnas sean idénticas (del mismo tipo) y si la columna de referencia no es primary_key , asegúrese de que esté INDEXED .
gracias S Doerin:
"Solo para completar. Este error también podría ser el caso si tiene una clave externa con VARCHAR (..) y el juego de caracteres de la tabla referenciada es diferente de la tabla que hace referencia a él. Por ejemplo, VARCHAR (50) en una tabla Latin1 es diferente de VARCHAR (50) en una tabla UTF8 ".
Resolví este problema, cambiando el tipo de caracteres de la tabla. la creación tiene latin1 y la correcta es utf8.
agrega la siguiente línea. CONJUNTO DE CARACTERES POR DEFECTO = utf8;
si todo está bien, solo agrega ->unsigned(); al final de la foregin key .
si no funciona, verifique el tipo de datos de ambos campos. deben ser lo mismo.