en los postcontroles del módulo 70_Historia_Académica nos dá un error de diferencia en las cantidades de movimientos migrados G2-G3: sga_movimientos_ha Error: Cantidad de movimientos_ha no coinciden… G2 2,00 G3 0
se trata en realidad de dos motivos agregados por la unidad académica a los 4 que trae por default G2
Mirando la lógica del script : fx_pos_ctrl_Hist_Academica, en la línea 45 pareciera está comparando motivos con movimientos
SELECT count(*) INTO cnt_motivos_ha_g3 FROM sga_movimientos_ha WHERE motivo_movimiento > 4;
Al cambiar por lo siguiente desaparece el error:
SELECT count(*) INTO cnt_motivos_ha_g3 FROM sga_movimientos_ha_motivos WHERE motivo_movimiento > 4;
Pueden corroborar que está correcta la modificación?
Hola Jorge, ese control que modificaste ya se esta haciendo antes, es el 1er control que se hace en esa funcion.
Lo que esta mal es el control sobre la tabla sga_movimientos_ha.
Te envio el script modificado. No va a servir si es una 2da, 3er… migracion ya que se debió contar al comenzar la migracion la cantidad de filas que tenia esta tabla.
Este script corregido reemplaza al original entonces?
Yo voy haciendo backup del eschema negocio después de migrar cada módulo correctamente. En caso de detectar error en algún módulo, si corrijo en G2 y vuelvo a generar el eschema mig, no me sirve entonces para restaurar la bd al último módulo correcto y continuar migrando desde alli?
Hola Jorge!
Sí, el script reemplaza al original y saldrá en la próxima versión con el ajuste realizado.
La observación de Ale respecto a que no va a funcionar el poscontrol si es la 2da o 3era migración, es porque al realizar el control de datos, previamente se fija en la cantidad de registros que existían en la tabla al momento de comenzar la migración.
Con respecto a tu consulta… podés modificar directamente los datos de la tabla de G2 del esquema ‘mig’ para no tener que tomarte el trabajo de volver a generar el esquema. En ese caso podrías utilizar el backup de la instancia anterior que no haya dado errores.
Si vos modificás algo en la base de G2 y volvés a generar el esquema mig, podés restaurar sólo la parte de la base de negocio ya migrada y continuar con la migración desde el siguiente módulo, pero tal vez te de algún error o incompatibilidad. Siempre lo mejor es realizar los ajustes de datos sobre el esquema mig directamente y así evitar generar el esquema.
El tema es que estamos migrando las bases de cada unidad académica en un ambiente de testing y los errores que detectamos los hacemos corregir en G2 de producción, para asegurarnos que al momento de la migración definitiva la bd pasa sin errores y minimizamos el tiempo que tengamos la aplicación inactiva para esa unidad académica. De alli la pregunta para agilizar el trabajo.