Inconsistencia en la cantidad de tuplas migradas

SIU-Guaraní Migración de Datos
1

Hola
Estamos haciendo las pruebas de migración a la versión 3.19.1.
En los precontroles de Pre_Controles_Actas.xls nos da el siguiente error:

Error: Hay actas de promoción con notas que no corresponden a la escala de notas del acta, verifique!!!

Haciendo la consulta equivalente en IFX, resulta no que no hay errores…
Así que mirando un poquito más en detalle, me encuentro que sólo pasaron 1800 tuplas de la tabla sga_det_escala cuando en realidad tiene 1902.

Alguna idea del motivo??
Gracias!!

Iris

2

Hola Iris, en casa uno de los mensajes de los pre-controles se envia la query para recuperar los registros con problemas, en este caso es la siguiente consulta:

SELECT a.acta, c.carrera, c.legajo, b.escala_notas, c.nota, c.resultado, c.estado 
FROM mig.sga_actas_promo as a, 
mig.sga_det_acta_promo as c 
WHERE a.unidad_academica = c.unidad_academica 
AND a.acta = c.acta 
AND c.nota IS NOT NULL
AND NOT EXISTS (SELECT nota FROM mig.sga_det_escala as b WHERE a.escala_notas = b.escala_notas AND c.nota = b.nota)

Fijate cuales son las actas de examen, cual es la nota que no existe en la escala de notas registrada en el acta de promoción.

3

Hola
Gracias por la respuesta.
Es que justamente la inconsistencia se da por tuplas que no migraron.
Existen en G2, pero no en G3.
Como explicaba, sólo pasaron 1800 tuplas de la tabla sga_det_escala cuando en realidad tiene 1902.
Si lo chequeo en G2 no encuentro ninguna inconsistencia, dado que las referencias a la tabla que define las escalas existen. En G3 NO migraron, y de ahí la inconsistencia…
Gracias!!
Saludos.

Iris

4

Iris, el error mencionado en tu 1er mensaje respecto de actas de promocion no tiene que ver con la tabla sga_det_escala (notas de escalas de notas)

¿Podes ver que escala de notas no pasó en su totalidad?
Corre la siguiente consulta:

-- Escalas de notas de G2
select escala_notas, nota from mig.sga_det_escala
except
-- Escalas de notas de G3
select m.escala_original, d.nota 
from mig._rel_esc_notas as m
JOIN sga_escalas_notas as e ON e.escala_nota = m.escala_notas
JOIN sga_escalas_notas_det as d ON d.escala_nota = e.escala_nota
order by 1,2
5

Hola Alejandro
Para poder avanzar, terminé pasando a mano los detalles de escala de notas que no habían sido pasados con el script de migración (en la prueba anterior de migración a 3.18 también me había ocurrido lo mismo).

En IFX corrí esto:

SELECT 'INSERT INTO mig.sga_det_escala(escala_notas, nota, descripcion, resultado, valor_numerico, concepto) '
    	|| 'VALUES (' || escala_notas || ', ''' || nota || ''', ''' || descripcion || ''', ''' || resultado 
    	|| ''', '  || valor_numerico::DECIMAL(5,2) || ', ''' || concepto || ''');' 
    FROM sga_det_escala;

Y las tuplas que faltaban las inserté en el esquema mig de G3.

Así que no se cual es el motivo por el cual se trunca la migración en las 1800 tuplas.

Iris

6

No habia entendido.
El problema esta en que no pasan de Guarani 2 (Informix) al esquema mig de Guarani 3.
Solo registros de la tabla “sga_det_escala” o tambien de la tabla “sga_escala_notas” ?

7

Hola Alejandro
Sólo sucede con la tabla sga_det_escala.
Y me sucedió en las 2 pruebas de migración que hice, en ambos casos las tuplas faltantes fueron las mismas.
Gracias!
Saludos.

Iris

8

Podes detectar algun patrón en los datos de los registros de notas que no se pasan a Postgres de los que si se pasaron?

9

Hola Alejandro

No hay un patrón en los datos que diferencie entre los que migran y los que no.

Por ejemplo, estas tuplas si migran:
6 9,59 Nueve.59 P 9.59 Distinguido
6 9,60 Nueve.60 P 9.6 Distinguido

Mientras que estas no:
6 10 Diez P 10.0 Sobresaliente
6 9,61 Nueve.61 P 9.61 Distinguido

Lo que sí noto, es que siempre migran los primeros 1800 registros (exacto). Y a partir del registro 1801 no pasa al esquema mig.
Me generé un script con los registros que faltan, y si lo corro a mano, los agrega sin problemas y puedo continuar con la migración.

Pero lo ideal seria que pasara automáticamente.

Gracias

Iris

10

Hola
Tal vez conviene revisar las variables de entorno de Pentaho. Por alguna razón quedo configurado un limite de 1800 dejo el link a la documentación de las variables
tambien podrian revisar la opcion avanzada de la configuración de base de datos de pentaho para ver que no quedara alguna opción seteada en 1800

Otra opción donde se puede setear un limite seria en el prectrl_Actas.kjb (o en el archivo que encontraron el limite) cuando editas el paso.

También podrían mirar las propiedades del pentaho en editar-> propiedades Kettle

Creo que son todas las opciones desde pentaho para setear algún limite.
Tal vez por alguna prueba quedo configurado ese limite
avísanos cualquier consulta
4
muchas gracias
saludos

11

Hola
No veo o no identifico ninguna de la propiedades del kettle que pueda estar afectando…
En prectrl_Actas.kjb no veo nada raro.
Aunque, tengo la idea que el error se da en el job IFX2PG, más específicamente en el trabajo “Pasar datos tablas”. Ya que el esquema mig es el que queda incompleto, llega a cargar sólo los primeros 1800 registros.
Lo raro es que existen otras tablas con más de 40 mil registros, y esos los pasa todos. Sólo ocurre con la tabla sga_det_escala.
Estuve viendo el link a la documentación de las variables, y tampoco identifico nada que pueda estar asociado.
Gracias

Iris

12

Si Iris, el problema esta en el proceso de pasaje de datos de Guarani 2 al esquema mig.
Lo raro es que tienen otras tablas con muchos mas registros y pasan todos.
Uds modificaron la tabla sga_det_escala en Guarani 2? ¿Algun campo con un nuevo tipo de datos?
Igualmente si hubieran cambiado y no esta contemplado ese nuevo tipo ode dato sde informix, daria error el proceso que crea la estructura de la base en el esquema mig.

13

Hola Alejandro
Ahí volví a correr un nuevo proceso de migración, y mirando los logs, encuentro esto:

2021/12/03 09:30:56 - Set Variables.0 - Setting environment variables...
2021/12/03 09:30:56 - Set Variables.0 - Set variable nombretabla to value [sga_det_escala]
2021/12/03 09:30:56 - Set Variables.0 - Finished after 1 rows.
2021/12/03 09:30:56 - Set Variables.0 - Procesamiento finalizado (EN=0, SA=0, LE=1, ES=1, AC=0, ER=0)
2021/12/03 09:30:56 - Setear variable - Entrada de comienzo [Copiar datos tabla]
2021/12/03 09:30:56 - Copiar datos tabla - Running transformation using the Kettle execution engine
2021/12/03 09:30:56 - Copiar una tabla - Iniciado despacho de la transformación [Copiar una tabla]
2021/12/03 09:30:56 - Table output.0 - Connected to database [conexion_pg] (commit=100)
2021/12/03 09:30:56 - Table input.0 - !TableInput.Log.FinishedReadingQuery!
2021/12/03 09:30:56 - Table input.0 - Procesamiento finalizado (EN=1869, SA=0, LE=0, ES=1869, AC=0, ER=0)
2021/12/03 09:30:57 - Table output.0 - WARNING: Couldn't insert row into table: [6], [], [Libre], [L], [null], [Libre]
2021/12/03 09:30:57 - Table output.0 -
2021/12/03 09:30:57 - Table output.0 - Error inserting/updating row
2021/12/03 09:30:57 - Table output.0 - ERROR: null value in column "nota" violates not-null constraint
2021/12/03 09:30:57 - Table output.0 -   Detail: Failing row contains (6, null, Libre, L, null, Libre).
2021/12/03 09:30:57 - Table output.0 - WARNING: Couldn't insert row into table: [4], [], [Libre], [L], [null], [Libre]
2021/12/03 09:30:57 - Table output.0 -
2021/12/03 09:30:57 - Table output.0 - Error inserting/updating row
2021/12/03 09:30:57 - Table output.0 - ERROR: current transaction is aborted, commands ignored until end of transaction block
2021/12/03 09:30:57 - Table output.0 - WARNING: Couldn't insert row into table: [3], [], [Libre], [L], [null], [Libre]
2021/12/03 09:30:57 - Table output.0 -
2021/12/03 09:30:57 - Table output.0 - Error inserting/updating row
2021/12/03 09:30:57 - Table output.0 - ERROR: current transaction is aborted, commands ignored until end of transaction block
2021/12/03 09:30:57 - Table output.0 - WARNING: Couldn't insert row into table: [7], [0], [Cero], [R], [0,0], [Reprobado]
2021/12/03 09:30:57 - Table output.0 -
2021/12/03 09:30:57 - Table output.0 - Error inserting/updating row
2021/12/03 09:30:57 - Table output.0 - ERROR: current transaction is aborted, commands ignored until end of transaction block
2021/12/03 09:30:57 - Table output.0 - WARNING: Couldn't insert row into table: [7], [1], [Uno], [R], [1,0], [Aplazado]
2021/12/03 09:30:57 - Table output.0 -
2021/12/03 09:30:57 - Table output.0 - Error inserting/updating row
2021/12/03 09:30:57 - Table output.0 - ERROR: current transaction is aborted, commands ignored until end of transaction block
2021/12/03 09:30:57 - Table output.0 - WARNING: Couldn't insert row into table: [7], [2], [Dos], [R], [2,0], [Aplazado]
2021/12/03 09:30:57 - Table output.0 -
2021/12/03 09:30:57 - Table output.0 - Error inserting/updating row
2021/12/03 09:30:57 - Table output.0 - ERROR: current transaction is aborted, commands ignored until end of transaction block
2021/12/03 09:30:57 - Table output.0 - WARNING: Couldn't insert row into table: [7], [3], [Tres], [R], [3,0], [Aplazado]
2021/12/03 09:30:57 - Table output.0 -

Con lo cual está identificada la falla!

El tema es que si luego a mano corro lo siguiente:


INSERT INTO mig.sga_det_escala(escala_notas, nota, descripcion, resultado, valor_numerico, concepto) VALUES (6, '', 'Libre', 'L', NULL , 'Libre');

Lo agrega sin problemas.
Necesitamos poder permitir al docente registrar que un alumno quedó libre en la cursada. Pero voy a ver de hacer los ajustes para manejarlo por la condición de regularidad y no por resultado.
Este inconveniente está asociado a la consulta que hice acá https://foro.comunidad.siu.edu.ar/index.php?topic=21885

Saludos
Iris

14

Iris, alli esta el problema, la nota en esa escala de notas que es un string vacío.
¿Porque hicieron eso?
Lo que sucede es que al pasar de Informix a Postgres el proceso lo que hace es pasar esos string vacios a NULL, por eso intenta registrar un NULL en el campo nota de la tabla mig.sga_det_escala y ahi falla.

¿En las actas tienen notas con el string vacio?
¿Podes correr esto en la base de informix?

SELECT * FROM sga_detalle_acta WHERE nota = '';
SELECT * FROM sga_det_acta_promo WHERE nota = '';
SELECT * FROM sga_det_acta_curs WHERE nota = '';

SELECT * FROM sga_det_escala WHERE nota = '';
Necesitamos poder permitir al docente registrar que un alumno quedó libre en la cursada
Si, esto se puede hacer, registrando una condición de regularidad que indique que quedó Libre, y donde esa condición de regularidad tiene asociado el [b]resultado ausente[/b] (resultado = U). Para los resultados "Ausente", no se carga la nota, es decir queda con NULL, y no con un string vacio. Esto sucede tanto en actas de cursadas, promociones y en los examenes donde el alumno estuvo ausente.
15

Hola Alejandro

Era por un tema que tenemos definido otro tipo de resultado, distinto a “A”, “R”, “P” y “U”, que es “L” (Libre).
Pero ya hice los ajustes para que sea la condición la que determine esa calidad, y no el resultado. Asociado al resultado “U”.

Sólo esta consulta devuelve resultado:

SELECT * FROM sga_det_escala WHERE nota = '';

Y son los 3 registros asociados a este cambio que tenemos.
Ahora hice los ajustes necesarios, y ya no tengo problemas para migrar la tabla sga_det_escala completa.

Gracias por todas la orientaciones.
Saludos.

Iris

16

Bien, si tenes resultados “L” en Guarani 2, te diria que cambies este resultado en las tablas del esquema mig:

UPDATE mig.sga_actas_detalle 
       SET nota = NULL, 
               resultado = 'U' 
  WHERE resultado = 'L';

Y esas escalas de notas con nota ‘’ fijate de setearle alguna nota o borrar ese registro de la escala de notas si tal nota no existe en ningun acta.

17

Hola Alejandro.

Si, esos ajustes ya los hice.
En todas estas tablas, ya que sólo se utiliza para las cursadas:

  • mig.sga_det_escala
  • mig.sga_cambios_curpen
  • mig.sga_det_acta_promo
  • mig.sga_det_acta_curs
  • mig.sga_hist_acta_curs
  • mig.sga_hist_acta_curs
  • mig.sga_cond_regular

Saludos.

Iris