Problema con claves foráneas

[cpuser]

Hola que tal, tengo un problema con una consulta que me da un error y no se porque.

la consulta es la siguiente:

Código MySQL:

INSERT INTO personas (nombre,apellido,ciudad,email,telefono,celular,usuario_id,tipopersona_id,estadocliente_id) values ('cd','','','','','','1','1','1')
 

o sin comillas simples (que tambien probe por las dudas):

Código MySQL:

INSERT INTO personas (nombre,apellido,ciudad,email,telefono,celular,usuario_id,tipopersona_id,estadocliente_id) values ('cd','','','','','',1,1,1)
 

me da el siguiente error:
#1452 - Cannot add or update a child row: a foreign key constraint fails (`avalith7_crm`.`personas`, CONSTRAINT `fk_personas_usuarios` FOREIGN KEY (`usuario_id`) REFERENCES `usuarios` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION)

Esta es la estructura de las tablas:

Código MySQL:

CREATE TABLE IF NOT EXISTS `tipopersona` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `nombre` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=3 ;
 
CREATE TABLE IF NOT EXISTS `estadocliente` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `nombre` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=12 ;
 
CREATE TABLE IF NOT EXISTS `usuarios` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `alias` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `clave` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `nombre` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `rol` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=4 ;
 
CREATE TABLE IF NOT EXISTS `personas` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `nombre` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `apellido` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ciudad` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `email` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `telefono` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `celular` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `usuario_id` int(11) DEFAULT NULL,
  `tipopersona_id` int(11) DEFAULT NULL,
  `estadocliente_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_personas_usuarios` (`usuario_id`),
  KEY `fk_personas_tipopersona1` (`tipopersona_id`),
  KEY `fk_personas_estadocliente1` (`estadocliente_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=21 ;
 
ALTER TABLE `personas`
  ADD CONSTRAINT `fk_personas_usuarios` FOREIGN KEY (`usuario_id`) REFERENCES `usuarios` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  ADD CONSTRAINT `fk_personas_tipopersona1` FOREIGN KEY (`tipopersona_id`) REFERENCES `tipopersona` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  ADD CONSTRAINT `fk_personas_estadocliente1` FOREIGN KEY (`estadocliente_id`) REFERENCES `estadocliente` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION;
 

por supuesto que en las tres primeras tablas tengo cargado con el id 1 algún dato:

Espero que alguien me pueda ayudar porque la verdad que ya me estuve volviendo loco.
Creo que el problema viene por el lado de las claves no se si están bien definidas o que (la base de datos la genere con el mysql workbench).

Desde ya muchisimas gracias a quien se tome el trabajo de leer todo esto y tirarme algun consejo.

[gnzsoloyo]

¿Y qué devuelven estas consultas?:

Código MySQL:

SELECT * FROM usuarios WHERE id = 1;
SELECT * FROM tipopersona WHERE id = 1;
SELECT * FROM estadocliente WHERE id = 1;
 

[leonardo_josue]

Apuesto mi postre a que alguno de las consultas regresa vacía...

cpuser, el insert no tiene nada de malo por lo que tal como lo sospecha gnzsoloyo y también lo sospecho yo, alguna de las tablas no tiene registro con id = 1... de hecho por la descripción del error la tabla usuarios es la que debe estar vacía...

Chécalo y nos comentas.

Saludos
Leo.

[cpuser]

si tengo datos eso es las mas raro, no había querido pegar todo para no hacer gigante el post les pongo el dumping

Código MySQL:

--
-- Dumping data for table `usuarios`
--
 
INSERT INTO `usuarios` (`id`, `alias`, `clave`, `nombre`, `rol`) VALUES
(1, 'Nati', '1234567', 'Nati', 'admin'),
(2, 'Agus', 'avalith1', 'Agus', 'Admin'),
(3, 'juanfran', 'avalith1', 'juanfran', 'Admin');
 
--
-- Dumping data for table `estadocliente`
--
 
INSERT INTO `estadocliente` (`id`, `nombre`) VALUES
(1, 'Proyectos Charlados'),
(2, 'Proyectos Presupuestados'),
(3, 'Proyectos Por Presupuestar'),
(4, 'Proyectos Seniados Activos'),
(5, 'Proyectos Seniados Congelados'),
(6, 'Proyectos Activos'),
(7, 'Proyectos Congelados'),
(8, 'Proyectos Terminados'),
(9, 'Proyectos Internos'),
(10, 'Proyectos En Desarrollo'),
(11, 'Proyectos Cancelados');
 
--
-- Dumping data for table `tipopersona`
--
 
INSERT INTO `tipopersona` (`id`, `nombre`) VALUES
(1, 'Oportunidad'),
(2, 'Cliente');
 

la verdad no se que puede ser...

[cpuser]

lo mas raro es que acabo de crear en otra base una prueba con los codigos que les pegue y me anda bien...

[jlct]

Hice lo mismo que cpuser cree una BD para probar y me realizo el insert sin problemas.. intenta realizando este insert

INSERT INTO personas (nombre,apellido,ciudad,email,telefono,celular,usu ario_id,tipopersona_id,estadocliente_id) VALUES ('cd','','','','','',null,null,null)

ya que definiste los FK con default null si funciona (a mi me funcionó), reemplazas los null por el 1...

prueba y me avisas!

[cpuser]

Para jlct : Probe con null y andaba pero con los valores 1 o '1' no funcionaba

La verdad que por fin lo pude arreglar pero nunca vamos a saber porque fallaba

Les cuento lo que hice y que me parece que fue..
La primera vez en mi cuenta de hosting cree la base de datos desde el panel y le puse mayúsculas por ejemplo : pepito_CRM
cree todas las tablas (por script) y luego pase el nombre de la base a minúsculas pepito_crm (ya ni me acuerdo porque lo hice) entonces empece a dar de alta datos en algunas tablas hasta que me tope con el problema con el que abri el tema.

Para arreglarlo borre la base de datos y cree otra en minúscula desde un principio y con otro nombre (por las dudas) y pegue el script (exactamente el mismo que la primera ves) solamente que esta ves no hubo ningún problema .....

Así que bueno lo unico que puedo concluir es que el cambio de nombre desde la sección avanzado del phpmyadmin no le gusto al cpanel o rompió algún permiso.

Asique bueno espero que mi experiencia sirva de ayuda para otros

Les agradezco mucho su ayuda y su tiempo.

[gnzsoloyo]

Así que bueno lo unico que puedo concluir es que el cambio de nombre desde la sección avanzado del phpmyadmin no le gusto al cpanel o rompió algún permiso.

No exactamente.
Posiblemente si hubieses explicado esos detalles del hosting desde el principio, hubiésemos tenido una idea más aproximada de lo que pudo pasar, o al menos de las cosas que había que revisar...
Me explico: En los servicios hosting que encuentras en la web es muy habitual que los servidores (de la base o del webserver) estén basados en Linux y no en Windows. Y eso hace una diferencia crítica.
Para Windows, poner "CONSTRAINT `fk_personas_usuarios`" o poner "CONSTRAINT `fk_Personas_usuarios`" es lo mismo, pero para Linux no.
Por empezar, una constraint de clase FK es un índice con ese nombre, que es lo que administra la relación entre ambas tablas, y como tal conforma un archivo. Como Linux puede diferenciar entre mayúsculas y minúsculas en los nombres de los archivos y otros objetos, ambos nombres se refieren a índices diferentes para él. Y como el manejo de archivos depende del sistema operativo y no a MySQL, se generan fácilmente conflictos casi indetectables por este asunto.
Como buena práctica de desarrollo de bases de datos se aconseja siempre que los nombres de todos los objetos de bases de datos estén siempre en minúsculas para evitar problemas de portabilidad, que parecen ser el corazón del asunto.

Habría que analizar el impacto que esos cambios tienen en los errores reportados.
Creo que es un tema para seguir verificando, ya a otro nivel.