Hola, después de la migración de G2 a G3.18.1 no quedaron mal unos planes de estudios.
Al migrar la primera base de una sede nos creó el plan 2010 de la propuesta Lic. en Sistemas de Información , y al migrar la segunda base de otra sede donde se dicta la misma propuesta nos creó el plan 2010_fcyt de la misma propuesta. Las actividades también están duplicadas pero con distinto id elemento para cada plan.
Ejemplo:
Carrera Lic. en Sistemas de Información (id: 68)
Plan 2010 (id: 72)
actividad Ingles I (id: 1456)
Plan 2010_FCYT (id: 133)
actividad Ingles I (id: 2533)
Los planes son los mismos y también las actividades son las mismas, debería estar todo unificado.
Se podrá arreglar modificando la base de datos? cambiando el plan del alumno en sga_alumnos y cambiando las actividades a los exámenes, equivalencias y comisiones.
O que nos recomiendan?
Haciendo referencia a tu pd, te quedó una ensalada mixta.
La migracion se realizó bien, es decir que se creó un plan de estudios nuevo para la misma propuesta con los alumnos de la 2da base migrada. Cada base migrada con su plan de estudios y sus alumnos.
¿Si las actividades quedaron duplicadas fue porque no tenian el mismo código pero si el mismo nombre, puede ser?
Esto se verifica en el script \02_Modulos\05_Tablas_Comunes\01_tablas_conversion.sql
Linea 625
Funcion: mig.aux_pk_materias
En las sucesivas migraciones de bases de G2, si se detectan que esas actividades ya existen, entonces da la posibilidad de reutilizar las actividades y no crear actividades nuevas. Que es lo que no sucedió en este caso.
¿Ya están en producción?
El problema aca es que todo se creó a partir de los nuevos ids de actividades. Cambiar eso es cambiar estos ids en muchas tablas de la base (planes, comisiones, mesas de examen,…).
Por favor comentanos en que estado estan de la migración y ver que posiblidad hay de volver a migrar ajustando esta validación para que se reutilicen las actividades que ya existen o como proceder en el caso que ya esten en producción.
Hola Ale. Si, ya estamos en producción desde noviembre, así que no habría posibilidad de volver a migrar.
Ahora estamos en versión 3.18.1.
Entiendo que son varias tablas, solo cambiamos en sga_mesas_examen y sga_comisiones como para hacer una prueba y no parece generar algún problema, pero no se si hay alguna tabla que no esté haciendo referencia o que el campo elemento tenga otro nombre, no quisiera entrar en una bola de nieve.
gracias!
Cambiar el dato de actividad (elemento) en las siguientes tablas:
Cambiar las tablas de mesas de examen y comisiones (sga_mesas_examen, sga_comisiones).
Es decir cambiar el campo “elemento” de la actividad que se creó en la ultima migración por la actividad que ya existe en la base de migracion anterior.
En las equivalencias. (sga_equiv_otorgada, sga_equiv_internas)
En las homologaciones. (sga_reconocimiento_act)
Si el plan tiene optativas compartidas, cambiar el dato [b]optativa /b y generica de sga_alumnos_optativas
Si tenian encuestas para esas actividades del plan, entonces cambiar el dato elemento de gde_items
En las tesis de los alumnos (sga_tesis)
Las orientaciones (modulos del plan) en las tablas sga_alumnos_orient y sga_alumnos_orient_mov
En el caso que el plan tenga orientaciones y el alumno debia elegir que orientación cursar.
Alumnos:
Cambiar el dato de la version de plan en (campo plan_version) del nuevo migrado por el que van a cambiar ya existente en la base de G3:
a) Inscripcion a propuesta (sga_propuestas_aspira)
b) En la tabla de alumnos (sga_alumnos)
c) En el historico de cambios de plan de estudios. (sga_alumnos_hist_planes)
d) En las inscripciones a cursadas y examenes (sga_insc_cursada, sga_insc_examen)
e) En las actas de examen abiertas y cerradas: sga_eval_detalle_cursadas, sga_eval_detalle_examenes, sga_actas_detalle
f) En las equivalencias: sga_equiv_tramite
e) En las aprobaciones por resolucion (homologaciones). (sga_reconocimiento)
g) En los titulos obtenidos (sga_certificados_otorg)
Posiblemente me falte algunas…
Esta query puede ver que tablas hacen referencia a un campo de una tabla. No significa que deban cambiar todas las tablas, ya que el plan que se creó con la ultima migracion ese lo van a dejar y en todo caso luego lo daran de baja cuando no tenga alumnos.
select conname as "Foreign Key",
t1.relname as "Tabla que referencia",
a1.attname as "Columna que referencia",
t2.relname as "Tabla referenciada",
a2.attname as "Columna referenciada",
'UPDATE ' || t1.relname || ' SET ' || a1.attname || ' = <NUEVO> WHERE ' || a1.attname || ' = <ANTERIOR>;' as sql_update
from pg_constraint as c,
pg_class as t1,
pg_class as t2,
pg_attribute as a1,
pg_attribute as a2
where a2.attname = 'elemento'
and t2.relname = 'sga_elementos'
and c.conrelid = t1.relfilenode
and t2.relfilenode = c.confrelid
and a1.attrelid = t1.relfilenode
and a2.attrelid = t2.relfilenode
--and a1.attnum = any (c.conkey)
--and a2.attnum = any (c.confkey)
and (
( c.conkey[1] = a1.attnum and c.confkey[1] = a2.attnum ) OR
( c.conkey[2] = a1.attnum and c.confkey[2] = a2.attnum ) OR
( c.conkey[3] = a1.attnum and c.confkey[3] = a2.attnum ) OR
( c.conkey[4] = a1.attnum and c.confkey[4] = a2.attnum ) OR
( c.conkey[5] = a1.attnum and c.confkey[5] = a2.attnum ) OR
( c.conkey[6] = a1.attnum and c.confkey[6] = a2.attnum ) OR
( c.conkey[7] = a1.attnum and c.confkey[7] = a2.attnum ) OR
( c.conkey[8] = a1.attnum and c.confkey[8] = a2.attnum ) OR
( c.conkey[9] = a1.attnum and c.confkey[9] = a2.attnum ) OR
( c.conkey[10] = a1.attnum and c.confkey[10] = a2.attnum )
)
order by conname
;