El proceso tira el siguiente error (solo les envio las ultimas lineas por que es muy extenso el log):
014/11/06 16:51:17 - Table exists - ALTER TABLE mig.mig_examenes
2014/11/06 16:51:17 - Table exists - ADD CONSTRAINT fk_migexa_turno18 FOREIGN KEY (anio_academico, turno_examen)
2014/11/06 16:51:17 - Table exists - REFERENCES mig.sga_turnos_examen ;
2014/11/06 16:51:17 - Table exists -
2014/11/06 16:51:17 - Table exists - analyze;
2014/11/06 16:51:17 - Table exists -
2014/11/06 16:51:17 - Table exists - ERROR: inserción o actualización en la tabla «sga_detalle_acta» viola la llave foránea «fk_det_acta_acta»
Detail: La llave (unidad_academica, tipo_acta, acta)=(10, R, 1186) no está presente en la tabla «sga_actas_examen».
Los datos fuentes si se encuentran en la BD Informix que estamos migrando.
Victor, la migracion de la tabla sga_actas_examen termino en forma correcta?
Hace una query para verificar si en mig.sga_actas_examen existen los datos que muestra el error ((unidad_academica, tipo_acta, acta)=(10, R, 1186)).
Saludos, Noemi
Noemi,
te contesto, ya que trabajo con Victor.
La migración de todas las tablas termino de forma exitosa.
Lo que notamos, es que no sabemos porque, en la BD postgres agrego “espacios” en algunos campos, ya que el acta 1186 existe, pero con un espacio detras, existe como "1186 “, y en la BD de producción informix, existe sin espacios. Hicimos el update sobre el acta, y seguimos… pero nos dio un error similar en la tabla sga_folios_actas_de_examen, donde a un libro le agrego un espacio en el campo Libro que es solo numérico.
Les recuerdo que en nuestra facultad, comentamos el script que cuando tomaba los datos de la BD de produccion hacia el TRIM, ya que tenemos turnos de examen que se llaman “Especial” y otro " Especial” y nos traía problemas ese TRIM.
Siguiendo consejo de Alejandro Delú comentamos la línea que hacía el trim.
Espero sus respuestas.
Saludos.
En postgres ese campo de la tabla quedo con el tipo de dato varchar o char? Porque tal vez si es char, es alli donde quedan espacios a derecha, porque en los campos de este tipo de datos “char” el campo se completa con caracteres…
Quizas por este motivo se habia puesto el TRIM… Recuerdo que algun problema había al pasar de informix a postgres respecto de estos campos con blancos a izquierda o derecha, pero lamento no tener el problema exacto que habia con este tema.
Tal vez el script pueda mejorarse y solo aplicar el trim sobre los campos que son parte de las PK de las tablas…