Buenas, nosotros estamos teniendo el mismo error. Tenemos instalada la versión 2.9.3 y actualizamos la base de datos a 2.9.4 para migrar a 3.14.
Hacemos las correcciones por sistema pero al efectuar los pre_controles vuelven a repetirse los errores. Detectamos que en datos censales se agrega el nuevo registro actualizado y corregido pero el script de migración al parecer efectua el control contra el primer registro porque sigue repitiendo el error.
Estamos ejecutando el trabajo 02_Modulos\00_Precontroles\Precontroles.kjb
Los errores están en la salida Pre_Controles_Personas.xls
Y uno de los querys que genera el procedimiento y muestra el error es
SELECT DISTINCT loc_per_lect FROM mig.sga_datos_censales WHERE loc_per_lect IS NOT NULL AND loc_per_lect NOT IN (SELECT localidad FROM mug_localidades)
Hola Claudio, abrimos hilo aunque se referencie a otro foro.
¿Están probando con la última versión de scripts de migración? ¿Por cuál motivo prueban migrar a una 3.14 cuando la 3.15 lleva publicada varios meses?
Una vez corregido los datos ¿uds vuelven a probar la migración en una base vacía o sólo completada con el script anterior?
Hola Emilse, actualizamos a la versión 315.1 y seguimos con el mismo problema, no toma los cambios realizados en datos censales, siempre valida con el 1 er registro de la tabla.
Claudio, esta query, les retorna alguna localidad?
Si retorna valores, significa que hay campos de localidades en la tabla sga_datos_censales, campo loc_per_lect que no existe en Guarani 3 en la tabla de localidades y que al migrar los datos censales va a dar error por no existir esa localidad.
SELECT DISTINCT loc_per_lect
FROM mig.sga_datos_censales
WHERE loc_per_lect IS NOT NULL AND loc_per_lect NOT IN (SELECT localidad FROM mug_localidades);
Respecto de lo siguiente:
Actualizamos a la versión 315.1 y seguimos con el mismo problema, no toma los cambios realizados en datos censales, siempre valida con el 1 er registro de la tabla.
¿Podes enviar una captura de pantalla con el error?
si, retorna códigos de localidad, pero nosotros limpiamos el registro del alumno pusumos en null todo los datos que hacen al domicilio que da el el error, pero sigue viendo el registro anterior como si no existiera el registro modificado.
SELECT unidad_academica, nro_inscripcion, cp_per_lect FROM mig.sga_datos_censales
WHERE cp_per_lect IS NOT NULL AND NOT (cp_per_lect ~ '[0-9][0-9][0-9][0-9]' OR cp_per_lect ~ '[A-Za-z][0-9][0-9][0-9][0-9][A-Za-z][A-Za-z][A-Za-z][A-Za-z]' ):.
En los datos del alumno donde nos da el error (cp_per_lectivo, cp_allegado ,cp_procedencia) limpiamos los datos pero no toma el cambio.
Claudio, se pasan TODOS los datos censales.
El dato censal con última fecha de relevamiento se pasa a la tabla sga_datos_censales y el resto de los datos censales anteriores se pasan a la tabla historica his_datos_censales.
Por eso es que validamos todos los datos censales el actual (ultimo) y los anteriores.
Si esa localidad no existe en Guarani 3 hay dos opciones antes de migrar:
Dar de alta esas localidades que devuelve esa consulta del pre-control en Guarani 3
Borrar esos datos de localidades inexistentes en Guarani 3 de la tabla del esquema de migracion (mig.sga_datos_censales).