cambiar toda la base de datos de MyISAM a innoDB

[oscarbt]

Buenas, para algunos este tema esta repetido pero nuevamente lo publico por lo suguiente:

He cambiado cada una de mis tablas de la bse de datos al ALmacenamiento innoDB
a traves del ALTER TABLE

En el php.inic ya esta habilitado innoDB

Sin embargo en la siguiente imagen, publico la forma como me sale la estructura de la base de datos, pareciera que solo las tablas estan con innoDB, pero no se si este mal pero veo que la base de datos aparece como MyISAM
Y hago pruebas y no hay nada de integridad referencia, (tengo definidos bien los indices y llaves)

Aca la imagen:



como pueden ver las tablas aparecen en InnoDB, pero porque sigue apareciendo abajo MyISAM?

Agradezco me indiquen como puedo dejar totalmente la base de datos en innoDB

GRacias

[gnzsoloyo]

Una base en sí no tiene tipo MyISAM o InnoDB. No es parte de las propiedades de la base, por ese lado no hay nada que hacer.
A una base le puedes definir el CHARSET, pero no el motor de tablas, que pertenece a las tablas.
Lo que sí puede ser es que aparezca como MyISAM porque ese sea el motor de tablas por default del servidor donde estás trabajando, especialmente si es en web. Pero no significa que afecte en algo a las tablas de la base que operas.

[oscarbt]

mmmm ya....una ultima pregunta

Porque si tengo mis tablas con innoDB, permite eliminar filas con integridad referencial?

Por ejemplo:
Tengo mi tabla ciudad, con el campo COD_CIU como primario

y tengo mi tabla egresado, en donde el campo COD_CIU es foranero

El sistema me deja eliminar cualquier registro de la tabla ciudad, aun sabiendo que ese dato se encuentra en la tabla egresado....

A que se debe esto?.........Gracias por la orientación........

[gnzsoloyo]

El sistema me deja eliminar cualquier registro de la tabla ciudad, aun sabiendo que ese dato se encuentra en la tabla egresado....

A que se debe esto?

Hay que revisar que la definición de las tablas sea correcta.
Por caso, postea el resultado de esta consulta:

Código MySQL:

SHOW CREATE TABLE egresado;
 

Puntualmente esto devolverá la sentencia CREATE TABLE que genera la tabla y veremos cómo está definida.

[oscarbt]

aparece lo siguiente(para esa tabla):

Código SQL:

CREATE TABLE `egresado` (\n  `NUM_CED_EGR` BIGINT(11) NOT NULL,
\n  `COD_SEC_LAB` INT(11) NOT NULL,
\n  `COD_CIU` INT(11) NOT NULL,
\n  `COD_TIP_DOC` INT(11) NOT NULL,
\n  `COD_SIT_LAB` INT(11) NOT NULL,
\n  `GEN_EGR` CHAR(1) NOT NULL,
\n  `NOM_EGR` CHAR(25) DEFAULT NULL,
\n  `APE_EGR` CHAR(25) DEFAULT NULL,
\n  `FEC_NAC_EGR` DATE DEFAULT NULL,
\n  `NUM_LIB_MIL` CHAR(11) DEFAULT NULL,
\n  `DIR_EGR` VARCHAR(70) DEFAULT NULL,
\n  `TEL_FIJ_EGR` CHAR(13) DEFAULT NULL,
\n  `TEL_MOV_EGR` CHAR(10) DEFAULT NULL,
\n  `COD_EGR` CHAR(12) DEFAULT NULL,
\n  `EMA_EGR` VARCHAR(70) DEFAULT NULL,
\n  `FEC_HOR_REG` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,\n  PRIMARY KEY  (`NUM_CED_EGR`),
\n  KEY `FK_CIUDAD_EGRESADO` (`COD_CIU`),\n  KEY `FK_SECTOR_LABORAL_EGRESADO` (`COD_SEC_LAB`),
\n  KEY `FK_SITUACION_LABORAL_EGRESADO` (`COD_SIT_LAB`),
\n  KEY `FK_TIPO_DOCUMENTO_EGRESADO` (`COD_TIP_DOC`)
\n) ENGINE=innoDB DEFAULT CHARSET=utf8
 

por ejemplo el campo COD_CIU tiene la misma estructura que el de esta tabla egresado, int (11).

[gnzsoloyo]

Bueno, las tablas son InnoDB, eso es evidente. Y hay índices definidos sobre valores que deberían ser FOREIGN KEYs, pero las FK no están.
Esto puede suceder si la base fue creara originalmente sin especificar que la tabla debía ser InnoDB, y el servidor tenía definido como motor por default el MyISAM. Si no se indica específicamente InnoDB, MySQL le asigna el otro tipo sin preguntar.
Por esto es buena práctica poner en el script de creación de las bases los tipos de tabla en forma específica, y no dejar que lo resuelva el servidor.
Ahora bien, el script puede haber tenido la indicación de las FK, pero como MyISAM no posee FK, no las puede crear y solamente genera estos índices. Por cuestiones preventivas, indicar una FK en el CREATE TABLE, sobre un motor MyISAM no genera erroes, sino warnings, que no son lo mismo, por lo que simplemente ignoró el problema y creó la tabla.
¿Se entiende el inconveniente?
No se trata de un comportamiento erróneo, eso es lo que MySQL hace siempre en estos casos: Ignora cualquier indicación de FK si va a crear la tabla como MyISAM.

Dos soluciones:
1) Elimina todos los índices de cada tabla, que correspondan a FK, y vuelve a crear las FK, ahora con las tablas como InnoDB.
2) Borra la base y vuelve a crearla, asegurándote que en el script se indique específicamente el tipo de tabla InnoDB (ENGINE=InnoDB). Siempre.

[oscarbt]

Ok, ahora entiendo el problema....demasiadas gracias........