Error migracion 2.9.4 a 3.15.1

Buenos días
Estamos migrando una base desde guarani 2.9.4 a 3.15.1
Estamos en el Módulo Propuestas y nos surge un error en el script 10_sga_propuestas_relacion:
ERROR: null value in column “anio_academico” violates not-null constraint

La consola muestra lo siguiente:
2018/12/07 14:00:12 - 10_sga_propuestas_relacion - INSERT INTO mig._app_migracion ( modulo, fecha_generacion, fecha_actualiz, script_corrido )
2018/12/07 14:00:12 - 10_sga_propuestas_relacion - VALUES (‘PROPUESTAS’ , CURRENT_DATE, CURRENT_TIMESTAMP, 10 );
2018/12/07 14:00:12 - 10_sga_propuestas_relacion -
2018/12/07 14:00:12 - 10_sga_propuestas_relacion - ERROR: null value in column “anio_academico” violates not-null constraint
2018/12/07 14:00:12 - 10_sga_propuestas_relacion - Detail: Failing row contains (1, 7, null, null, 2018-12-07 14:00:12-03).
2018/12/07 14:00:12 - 10_sga_propuestas_relacion - Where: SQL statement “INSERT INTO sga_propuestas_relacion (propuesta, plan, anio_academico) VALUES (cur_rel.propuesta, NULL, _anio)”
2018/12/07 14:00:12 - 10_sga_propuestas_relacion - PL/pgSQL function mig._aux_propuestas_relacion() line 38 at SQL statement

Observamos que la tabla negocio.sga_anios_academicos está vacía y por eso devuelve un NULL que genera el error posterior.

Qué deberíamos hacer?
Gracias

Buenas tardes, que te devuelve el ejecutar esta query



SELECT i.unidad_academica, i.carrera, mcpp.propuesta, i.carrera_ciclocomun, cc.propuesta as propuesta_origen,
	extract(year from mig.sga_carreras.fecha_creacion) as anio_creacion
FROM mig.int_arau_car_cc as i,
     mig._cnv_pk_propuestas as mcpp,
	 mig.sga_carreras,
	 mig._cnv_pk_propuestas as cc
WHERE mcpp.unidad_academica = i.unidad_academica 
  AND mcpp.carrera = i.carrera
  AND mcpp.migrar = 1
  AND mig.sga_carreras.unidad_academica = i.unidad_academica 
  AND mig.sga_carreras.carrera = i.carrera
  
  AND cc.unidad_academica = i.unidad_academica 
  AND cc.carrera = i.carrera_ciclocomun
ORDER BY i.carrera

Saludos.

Te adjunto el resultado de la query.
Saludos


respuesta_foroSIU-111218.png

respuesta_foroSIU-111218.png

Por lo que veo según nos contas, la tabla sga_anios_academicos está vacía pero esto pudo haber pasado con varias universidades y aún asi no nos han reportado el error.
Supongo que estás en modo pruebas, si podes agrega el año académico 2019 para hacer una prueba y verificar si esto falla.

Saludos

El dato “2019” es solo para hacer una prueba o, si corrige el error, sería una solución definitiva?
Entiendo que al agregar el valor, ya no se produciría el error. Pero necesitaría saber cuál sería el dato correcto a insertar para poder seguir, de dónde obtenerlo para continuar con la migración. Porque se trata de un caso de prueba, pero simulando una migración de producción, que se va a realizar a continuación de ésta.

Te comento también que se realizó una migración de esta facultad, hará un año y medio o dos , y no surgió este error. Comparé los scripts de ambas versiones y no veo diferencias, por lo que no entiendo por qué falla en este caso.

Espero tu respuesta para continuar. Gracias!

Entiendo tu duda, puntualmente tampoco entiendo porque te da error.
Pero lo que si te puedo asegurar es que luego mas adelante vas a poder insertar correctamente los años académicos.

Saludos.

Mi preocupación es la repercusión que pueda tener a la hora de correr el script 10_sga_propuestas_relacion usando este dato de prueba.
Te copio la porción del script que me genera esta duda:
SELECT MIN(anio_academico) INTO _min_anio
FROM sga_anios_academicos;

IF cur_rel.anio_creacion < _min_anio THEN
_anio := cur_rel.anio_creacion;
ELSE
_anio := _min_anio;
END IF;

Estuve mirando esa porción de codigo que me pasas.
Entiendo que pueda generarte dudas esto al momento de hacer la migración.
Si queres podes hacer lo siguiente:

  • Comentar la línea de ese sql para que no corra la función que usa los años academicos
    ( select * from mig._aux_propuestas_relacion():wink:
  • Cuando terminas de correr el modulo de años academicos, hay un archivo que se llama personalizado.sql
    G2/02_Modulos/35_Calendario Academico/02_Migracion/90_personalizado.sql. Dentro de este podrías poner ese select que has sacado antes del otro script.

Saludos.

Pero si saco el select no influye en el insert? Te adjunto el script completo.


10_sga_propuestas_relacion.sql (2.88 KB)

Si quitas ese select del final no va a ejecutar las función, solo la va a crear a la función.
Luego como te indique en la respuesta anterior podes hacer que corra cuando creas los años académicos.

Saludos.

Buenos días

Te comento que probamos lo primero que nos indicaste. Agregamos el año 2019 en la tabla sga_anios_academicos , corrimos nuevamente el trabajo desde el script 10, y nos surgió el siguiente error:

2018/12/12 10:03:38 - 10_sga_propuestas_relacion - INSERT INTO mig._app_migracion ( modulo, fecha_generacion, fecha_actualiz, script_corrido )
2018/12/12 10:03:38 - 10_sga_propuestas_relacion - VALUES (‘PROPUESTAS’ , CURRENT_DATE, CURRENT_TIMESTAMP, 10 );
2018/12/12 10:03:38 - 10_sga_propuestas_relacion -
2018/12/12 10:03:38 - 10_sga_propuestas_relacion - ERROR: insert or update on table “sga_propuestas_relacion” violates foreign key constraint “fk_sga_propuestas_relacion_sga_anios_academicos”
2018/12/12 10:03:38 - 10_sga_propuestas_relacion - Detail: Key (anio_academico)=(2000) is not present in table “sga_anios_academicos”.
2018/12/12 10:03:38 - 10_sga_propuestas_relacion - Where: SQL statement “INSERT INTO sga_propuestas_relacion (propuesta, plan, anio_academico) VALUES (cur_rel.propuesta, NULL, _anio)”
2018/12/12 10:03:38 - 10_sga_propuestas_relacion - PL/pgSQL function mig._aux_propuestas_relacion() line 38 at SQL statement

Lo que no entiendo es por qué busca años académicos cuando todavía no se ha llegado a la migración del Módulo Calendario Académico. O sea, está bien que esté vacía esa tabla en esta instancia o es un error generado por algo previo?

Buenos días Natalia,
Entonces hiciste las modificaciones que te mencione en las respuestas #7 y ya tenes corridos los scripts del módulo años academicos?

Saludos.

No, hice lo que te comente, la prueba que nos indicaste en la respuesta #3. Y surgió ese error.

Ok, entonces proba lo que te comenté en la respuesta #7

Buenos días.
Te hago dos consultas:

1 - Me podrías indicar por favor exactamente que porción del script 10_sga_propuestas_relacion debería copiar en el script 90_personalizado del Módulo Calendario Académico? O sería literalmente solo la linea “select * from mig._aux_propuestas_relacion();”?
Y, además, qué consecuencias tendría hacerlo de esta forma? Es decir, por algo se sigue un orden, por eso consulto.

2 - Y por favor, podrías comentarme por qué busca años académicos cuando todavía no se ha llegado a la migración del Módulo Calendario Académico, o por qué estaría vacía la tabla sga_anios_academicos. O sea, está bien que esté vacía esa tabla en esta instancia o es un error generado por algo previo?
Es para entender como funciona. Disculpá la molestia.

Muchas gracias

Buenas tardes, como te comenté en el post 7 deberías quitar la línea que contiene esto del archivo G2/02_Modulos/25_Propuestas/02_Migracion/10_sga_propuestas_relacion.sql:

 select * from mig._aux_propuestas_relacion();

Y en el archivo
G2/02_Modulos/35_Calendario Academico/02_Migracion/90_personalizado.sql
Agregar ese select

Por favor probalo y comentanos.
Saludos.

Hola Natalia, el problema viene por el campo “fecha_creacion” de la carrera que no tiene un valor definido.
Tabla: mig.sga_carreras
Campo: fecha_creacion

Ya que usa el año de esta fecha para poder registrar la relación entre carreras que tienen definido en Guarani 2 (Tabla mig.int_arau_car_cc).
En Guarani 3 las definiciones de relaciones entre propuestas (por ejemplo un curso de ingreso y una carrera de grado) necesita que se le defina a partir de que año académico (cohorte) empezó a tener vigencia esa relación.

Por lo cual, deberías hacer algo de lo siguiente:

  1. Definirle una fecha de creación a la carrera por la cual estas teniendo problemas. Cargar una fecha en la tabla de migracion mig.sga_carreras en el campo fecha_creacion

  2. En el script 10_sga_propuestas_relacion.sql, dentro de la funcion “mig._aux_propuestas_relacion” donde dice:

extract(year from mig.sga_carreras.fecha_creacion) as anio_creacion

Cambiarlo por:

(CASE  WHEN mig.sga_carreras.fecha_creacion IS NOT NULL THEN extract(year from mig.sga_carreras.fecha_creacion) ELSE  xxxx END) as anio_creacion

donde en xxxx debes poner algun año desde el cual defininen que esa relacion entre propuestas comenzo a tener vigencia, por ejemplo 1980.


Para que no de error, veremos de poner un pre-control en estos casos de propuestas relacionadas donde no tengan definida esta fecha que es utilizada en este script.

Buenos días.

Escribo para comentarles que ya se había completado la migración en testeo, a fines de diciembre, utilizando la indicación de Jose Marino. Actualmente estamos esperando que la unidad académica revise los datos, para realizar la migración en producción.
Hay algún inconveniente con que hayamos utilizado esa solución? Sería necesario volver a ese punto y probar la solución del día 02/01/19 en lugar de lo que se nos indicó en su momento?

Saludos

No entiendo como funcionó pasando el llamado de esa funcion al script personalizado, ya que igual sigue tomando el año de la fecha del campo “fecha_creacion” de la tabla “mig.sga_carreras”.

Para que no tengan problemas, lo que podes hacer es dejar los scripts como estan sin modificarlos y completar el campo “fecha_creacion” de la tabla “mig.sga_carreras” para los casos donde esa fecha esta sin un valor. Al menos para las carreras que estan relacionadas porque el script saca el año de esa fecha de esas carreras para luego generar la relacion entre propuestas en Guarani 3.