El “errno: 150″ de MySQL
Visita este artículo en http://www.estadobeta.com/2008/03/16/el-errno-150-de-mysql/
Por vladimir en Desarrollo, Documentación, artículos, tipsNo fue hasta mucho tiempo después de conocer MySQL que conocí las tablas tipo InnoDb. Estas, a diferencia de su contraparte MyISAM, poseen varias cualidades que la hacen deseable. Por ejemplo: Integridad Referencial.
Lamentablemente InnoDb posee algunos peros. Uno de los más molestos es el “errn: 150″ que aparece al ejecutar alguna sql (típicamente CREATES y ALTER) mal formada o errónea. Esto porque no ofrece información adicional para saber cómo solucionarlo. Sólo ves un escuálido “errno: 150″.
Algo poco conocido (y usado), es el status de los diferentes motores. En el caso de InnoDb, la instrucción SHOW INNODB STATUS nos ofrece un montón de información. Entre esas, nos muestra información sobre la última instrucción sql rechazada. Con esto es posible obtener mayor información del error, que te ayudará a descrubrir su origen y cómo solucionarlo.
Para el conocido proyecto phpMyAdmin, no funcionará bien si ejecutas directamente la instrucción SHOW. En vez de ello, es mejor ir al home del software y pinchar en [Motores de Almacenamiento -> InnoDb -> Estado del InnoDb].
Ahora ya no tienes excusas para no solucionar esa escurridiza instrucción SQL 
FUENTE: manual de referencia oficial de MySQL
- Servicios:
- Comentarios RSS
- Menear!
- Del.icio.us
3/17/2008 at 12:41 am
Me pasó algunas veces, que dió ese error.
Recuerdo que siempre fue por que el tipo de campo definido para la llave foranea no era igual al padre. Y cuando son muchas tablas no es fácil reconocerlo, sobre todo si las diferencias son tan sutiles como SMALLINT una y INT la otra, cuando ambas debian ser iguales.
Saludos.
5/17/2008 at 11:28 pm
Encontré esta pagina en el segundo lugar simplemente poniendo “mysql errno 150″ en google y ya lo solucioné.
Muchas gracias por la explicación.
Para contar un poco nomas y que sirva como analogía de hasta donde rompe el rdbms: resulta que tenia un int(2) pero a uno le habia puesto unsigned y al otro lo habia dejado default… y kaput
Gracias otra vez
6/27/2008 at 6:14 pm
Muy bueno tu consejo Gracias, me paso lo mismo, y cambie mi campo para que se identico al del campo padre y funciono los alter table para la clave foranea.
codigo VARCHAR(10) NOT NULL
por el del padre que era este:
codigo varchar(10) character set utf8 collate utf8_bin NOT NULL