Cuando voy a la aplicacion obvio que aparece de la siguiente manera:
https://prnt.sc/tvcknl
Respecto a las escalas de notas, es correcto en la migracion no se hace una comparación de escalas de notas existentes y las que se van a migrar.
Porque el conjunto de notas podria ser el mismo y no asi los conceptos o la descripción de la nota. Con lo cual dejamos esto a un analisis que debe realizar la institución y decidir que hacer.
Adjunto un script que busca en la base escalas de notas que sean identicas, esto es que tengan el mismo conjunto de notas, resultados y conceptos.
De esta forma poder indentificar esas escalas de notas asi dan de baja una y dejan la otra para que no sea mas usada pero que quede en la base como referencia de las actas/equivalencias migradas.
Con respecto a la migracion de periodos lectivos me agrego esto
https://prnt.sc/tvcsne
cuando ya existia el dato y debia ser por:
Screenshot by Lightshot
Con los períodos lectivos genericos pasa lo mismo, aunque el script de migracion compara y no inserta el periodo lectivo generico si ya existe, compara por el nombre pero por el nombre exacto. En el ejemplo que envias en uno es “anual” y en otro “Anual”, hay diferencia de minúsculas/mayúsculas.
Lo que pueden hacer es en la tabla
sga_periodos_genericos, aquellos que esten duplicados es desactivar el periodo genérico (cambiar el campo “
activo” de S a N) y reemplazar en los períodos lectivos este periodo genérico que desactivan por el que lo reemplaza (sga_periodos.periodo_generico)
De la misma manera pasa con los requisitos, un ejemplo
En una UA se llama DNI en otra Documento Nacionalidad de Indentidad y la otra opcion es Documento Nacional de Indentidad y me migro los 3 cuando lo podría haber migrado una vez y que las demás UA se remplacen por esto antes de terminar de migrar y evitar la duplicidad de datos.
Con los requisitos pasa lo mismo que los periodos genericos, compara por el nombre del requisito de ingreso. Si el nombre no es exactamente igual, entonces lo va a migrar como un nuevo requisito.
Las opciones es que normalicen ese nombre en cada base que vayan a migrar. Lo pueden cambiar en la base de Guarani 2 o lo pueden cambiar en la tabla del esquema mig, luego que pasan los datos de Guarani 2 a Guarani 3. Esto hara que cuando se migren esos requisitos,los detecte en la base de G3 y no los genere nuevamente como nuevos requisitos.
Se imaginan si tengo que migrar 7 unidades y esto se repite asi, desde la aplicación no queda muy limpia la info, y tendría que hacer tantos reportes como opciones 'distintas' sean cuando en realidad es la misma opción pero escrita de distinto modo.
No deberias hacer nuevos reportes sino ajustar los datos antes o despues de cada migración según la solución propuesta en cada punto anterior.
4
buscar_escalas_de_notas_duplicadas.sql (5.13 KB)