Buenas.

Estamos teniendo un problema en los post-controles de la migración de actas. Adjunto archivo.

En resumen, en la linea de sga_eval_detalle_examen el G2 supera por 1289 registros al G3. Este inconveniente es nuevo de esta versión debido a que en la versión 3.18 no se presentó dicho problema.

Mirando en el archivo fx_pos_ctrl_actas.sql hay una consulta SELECT que en la versión 3.18 no estaba y es ésta la que causa la disparidad de los números.

La nueva consulta es

SELECT COUNT(*) INTO cnt_insc_examen_g2_no_estan_en_acta
     FROM mig.sga_insc_examen as ie,
          mig.sga_actas_examen as msa 
     WHERE ie.unidad_academica = msa.unidad_academica AND
           ie.anio_academico   = msa.anio_academico AND
         ie.turno_examen     = msa.turno_examen AND
         ie.llamado          = msa.llamado AND
         ie.mesa_examen      = msa.mesa_examen AND
         ie.materia          = msa.materia AND
           msa.estado IN ('A','I','N') AND
         NOT EXISTS (SELECT 1 FROM mig.sga_detalle_acta as d
         WHERE d.unidad_academica = msa.unidad_academica
           AND d.tipo_acta = msa.tipo_acta
           AND d.acta = msa.acta
           AND d.carrera = ie.carrera
           AND d.legajo = ie.legajo)       
         ;

y si la ejecuto, me arroja precisamente 1289 registros.

Ahora, la suma de las consultas

SELECT count(*) INTO cnt_eval_det_exa_g2
     FROM mig.sga_detalle_acta as sda,
          mig.sga_actas_examen as msa 
     WHERE sda.unidad_academica = msa.unidad_academica AND
           sda.tipo_acta = msa.tipo_acta AND
           sda.acta = msa.acta AND
           msa.estado IN ('A','I','N');

y

SELECT count(*)  INTO cnt_eval_det_exa_reval_g2
     FROM mig.sga_det_acta_reval as sda,
          mig.sga_actas_reval as msa 
     WHERE sda.unidad_academica = msa.unidad_academica AND
           sda.acta_revalida = msa.acta_revalida AND
           msa.estado NOT IN ('B','C');

me da 437 registros que son exactamente los mismos que los que me dan las consultas que suman los registros del g3.

Nos gustaría saber por qué se agregó esa nueva consulta, si puede ser omitida (ya que en 3.18 no estaba) y en caso de que no se pueda omitir, cómo solucionar el problema. Gracias!

Gracias Alejandro, módulo Actas migrado

Buenas, desde la universidad UNaM, facultad FCEQyN estamos teniendo el mismo problema. Nos interesaría saber en caso de ser posible cómo fue que se resolvió. Qué consulta se realizó, qué tabla se modificó, si lo hicieron mediante el sistema o manipulando la base de datos, etc. Gracias! 

Buen dia Alejandro! asi es.. borré los indices y los volvi a generar, eso solucionó el problema.

Paso a detallar lo realizado:
*****************************************************************************
--Para buscar las fk e indices asociados de una tabla realizar la siguiente consulta:
******************************************************************************
 SELECT informix.systables.tabname,   
            informix.sysconstraints.constrname,   
            informix.sysconstraints.constrtype,   
            informix.sysconstraints.idxname,   
            informix.sysindexes.idxtype,
            informix.sysreferences.primary,
            informix.sysreferences.delrule,
            (SELECT tabname from systables where tabid = informix.sysreferences.ptabid) as tabla_referenciada
       FROM informix.sysconstraints,   
            informix.systables,   
            OUTER informix.sysindexes,
            OUTER informix.sysreferences
      WHERE ( informix.systables.tabid = informix.sysconstraints.tabid ) and
            ( informix.sysconstraints.idxname = informix.sysindexes.idxname ) and
            ( informix.sysconstraints.constrid = informix.sysreferences.constrid )
      and informix.systables.tabname = 'sga_detalle_acta' 
order by informix.systables.tabname ;

*****************************************************************************
--Borrar y regenerar los indices nuevamente:
*****************************************************************************
--Borré cada indice de la sgte. manera:
ALTER TABLE "dba".sga_detalle_acta  DROP CONSTRAINT "dba".pk_detalle_acta;

--Regeneré cada indice:
ALTER TABLE "dba".sga_detalle_acta
       ADD CONSTRAINT primary key (unidad_academica,tipo_acta,acta,carrera,legajo)
         constraint "dba".pk_detalle_acta

Esto solucionó el problema.
Gracias por responder.
Saludos,
Daniela Rolón
FCEQyN - UNaM

Eel campo "fecha_egreso" esta configurado como  varchar(8).

Buenas tardes Alejandro, me tira el mensaje "3577, Generación de información nominal de alumnos finalizada..."
No  arroja ningún error.

Buen dia Alejandro, volví a importar todo en power builder y generó los archivos sin problemas.
Muchas gracias.

Saludos,
Daniela

Estimado Ariel,

Se debe modificar la función sp_ctrl_generales()  ya que falta hacer referencia al esquema mig y por eso no encuentra la relación mug_localidades

mig.sp_ctrl_generales()  - line 19
IF EXISTS (SELECT localidad, codigo_postal FROM mig.mug_cod_postales WHERE localidad NOT IN (SELECT localidad FROM mig.mug_localidades  UNION SELECT localidad FROM mug_localidades)) THEN
      sql=E'SELECT localidad, codigo_postal FROM mig.mug_cod_postales  WHERE localidad NOT IN (SELECT localidad FROM mig.mug_localidades  UNION SELECT localidad FROM mug_localidades)';
      
Reemplazar por:
IF EXISTS (SELECT localidad, codigo_postal FROM mig.mug_cod_postales WHERE localidad NOT IN (SELECT localidad FROM mig.mug_localidades  UNION SELECT localidad FROM mig.mug_localidades)) THEN
      sql=E'SELECT localidad, codigo_postal FROM mig.mug_cod_postales  WHERE localidad NOT IN (SELECT localidad FROM mig.mug_localidades  UNION SELECT localidad FROM mig.mug_localidades)';

Después deberás ejecutar el Spoon desde la tarea Generales en adelante.

Saludos cordiales,

Mónica Mounier

Estimados:

Estoy trabajando en la versión  V 2.9.3 y me encontré con el siguiente problema al ejecutar la operación ifz00003  (Orden 2: Actualizar Alumnos y egresados):

Al intentar ejecutar esta operación para el año académico 2018 y al momento de guardar los datos de los Reinscriptos me tira el siguiente mensaje: “A subquery has returned no exactly one row.”

Indagando entre las tablas que se cargan y los sp que se ejecutan, detecte que el sp que tira el error es el sp_int_arau_ingrei.
Ejecute este sp en forma aislada y me tira este mensaje.

Aparentemente existen registros con la misma información, por eso salta este mensaje.
La consulta es, como poder identificar cual es el registro que esta dando problemas?...
Ya que este sp recupera datos de cada legajo en muchas tablas para obtener la información necesaria y realizar la carga final.

Saludos.
Daniela
FCEQyN - UNaM