Problema extranísimo al querer cargar asistencias - Versión 2.7.0

Gente:

Tengo un problema bastante extraño cuando los usuarios quieren cargar inasistencias y necesito si alguien me puede ayudar a encontrar problema y solución.

En la operación asi00001, cuando intentaron cargar las inasistencias de algunas comisiones (no todas), sale el mensaje “No se encontraron comisiones en el período lectivo seleccionado” a los operadores de la mañana. A la tarde pasé yo a ver el problema, y funcionó perfectamente, trayendo la comisión. Eso fue antes de ayer. Año lectivo 2017, periodo lectivo anual, materia 503R. Con las materias del 1er. Semestre no pasa.

Hoy volví y cuando intenté hacer lo mismo para mostrar que funcionaba bien, me dió nuevamente el mensaje a mi!!

Intenté mil cosas y siempre el mismo mensaje de error. Entre lo que intenté volví a grabar los datos del período y sus tramos, volví a grabar los datos de la comisión, volví a grabar los datos de la asignación de banda horaria, etc. En 2 o 3 opciones, la pantalla inicial del filtro da el mismo mensaje. Pero luego ingresé a otras opciones y vi que los datos de las inasistencias estaban cargados!!!

Luego entré a ver como era el Select de la DW de filtro inicial, que es la que da ese mensaje, y el Select ejecutado por SQLEditor funciona perfecto, trae el registro de la comisión del caso. Por las dudas, ejecuté varios oncheck de datos y de indices.

Luego entré a ver los datos las tablas y algunas tablas de log , y parecía estar todo bien, pero la operación asis0001 no funcionaba:

select * from sga_inasis_acum where comision = 7059;
select * from sga_inasis_tramos;
select * from sga_inasistencias where comision = 7059;
select * from sga_calendcursada where comision = 7059;

select * from log_inasis_tramos;
select * from log_calendcursada where comision = 7059;
select * from log_inasis_acum where comision = 7059;

Ya perdido, empecé la redacción de este mensaje para ver si me podían ayudar, y cuando voy a ejecutar la operación para corroborar el mensaje de error, opss!! Me funcionó!!

De todas maneras, terminé la redacción del mensaje porque no sé si en un rato, o mañana va a dejar de funcionar de nuevo!! Se les ocurre que puede ser???

Saludos

Es un caso muy raro el que esta sucediendo.
Fijate de actualizar las estadisticas de los datos y procedures.

Cuando sucede que da ese mensaje que no enuentra comisiones en el período lectivo seleccionado, probaste correr varias veces esa operacion en ese momento hasta que puedas lograr recuperar las comisiones? Pensando en que en ese momento algun registro de la tabla de comisiones estuviera bloqueado o alguna página de esa tabla y que al momento de consultar no devuelva las filas, lo raro es que deberia salir por error y el mensaje pareciera ser que es porque la consulta no devuelve filas.

La datawindows que se ejecuta alli se llama “dk_comisiones_un_periodo”
Si miras esa datawindow recupera comisiones del periodo lectivo seleccionado y de la materia (si se seleccionó una materia). Solo recupera comisiones con fecha de inactivacion (definida en el período lectivo) mayor o igual a hoy y que esten definida para la sede del usuario que hace la consulta y que la comision no tenga subcomisiones.
Pareciera que el filtro por fecha de inactivacion y sede no deberia ser el problema ya que en algun momento pudiste recuperar esos datos.
¿Tienen subcomisiones?
¿Cuando te sucedio eso, seleccionaste una materia en el filtro de búsqueda o estaba solo seleccionado el año academico y periodo lectivo?

¿Intentaron por autogestion si tambien les sucede lo mismo?

¿Estan generando comisiones o corriendo algun proceso de actualizacion masivo que haga que por algun instante bloquee registros de algunas tablas y en ese momento sea que les da ese mensaje?

Fijate de ejectuar algun reporte donde tengas un filtro de periodos lectivos y recuperes comisiones, a ver si sucede lo mismo cuando te sucede ese error en la operacion de carga de asistencias.

Gracias Ale por contestar! Como vos decis es muy raro.

  1. Tu primer comentario, de registros o páginas bloqueadas fue de las primeras cosas que se me ocurrió, por eso una de las primeras pruebas fue bajar el motor (onmode -u) y volverlo a levantar (onmode -m) para sacar a los 2 usuarios logueados en ese momento. Después de asegurarme que no hubieran usuarios logueados ejecuté la operación y no funcionaba.

  2. Hoy le pedí a Magalí (colabora con nosotros en la EST) que probara ya que ella me reportó el problema y parece que funcionó bien.

  3. Sede hay 1 sola, no tienen subcomisiones, para todas las pruebas elegía año académico, período lectivo y materia, ya que era el ejemplo que tenía reportado como problema.

  4. No usan autogestión para la carga de asistencias.

  5. Las comisiones están todas generadas, ya se hizo toda la inscripción y la inscripción está cerrada como hace 1 mes

Aparentemente ahora funciona bien. No sé si fue un problema de bloqueo de una tabla y el bloqueo permaneció a pesar que “maté” los usuarios, por algún tema de caché, y luego se desbloqueó después de un tiempo o porque volvieron a ingresar esos usuarios. La verdad no sé que pensar. Me queda pendiente ver si esas tablas se están bloqueando a nivel de ROW o de PAGE, ya que me tuve que ir ayer. Eso es lo único que se me ocurre que puede haber sucedido.

Saludos

Gustavo

La tabla de comisiones creo esta a nivel de fila el bloqueo, sino lo esta podés cambiarle el bloquedo a nivel de fila.

Ale:

Ayer volvió a aparecer este problema. Hoy lo verifico y sigue dando el mensaje que no existen comisiones. No hay otros usuarios conectados a la base. El lockeo de la tabla de comisiones está a nivel de ROW.

Que podrá ser? le estoy volviendo a correr los checkeos, pero la verdad es que estoy perdido!! Los oncheck dan todos bien. Una cosa extraña es que si ingreso por la operación aul0003 - Asignación de bandas horarias, que tiene los filtros iniciales, esto es por año académico, periodo lectivo y materia, iguales a la operación asi00001 (lo cual no significa que el SQL que se ejecuta sea igual), pero en esa operación encuentra la comisión y luego muestra correctamente las bandas horarias en la pantalla siguiente …

Un verdadero misterio …

Saludos

Gustavo, no es que nunca les funciono esa operación.
A veces recupera las comisiones y a veces no, hablnado del mismo año academico y período lectivo. Eso es lo extraño!
Los logical logs estan backupeados?
Cuando pase eso fijate si podes entrar al motor y tirar el comando “onstat -a > onstat_a.txt” (si es windows. En linux fijate como volcar el contenido de la salida de ese comando a un archivo)
Para ver si el motor informa algo de lo que este pasando en ese momento.

Alejandro:

A veces funciona y a veces no!!! Eso es lo raro!! hablando del mismo año académico, mismo periodo lectivo y misma materia y comisión (por suerte es una única comision de esa materia).

Los lógical logs están backupeados, se hace una tarea programada 1 vez por día que los backupea. Te adjunto el onstat -a de este momento, en que me da el error. Estoy viendo de obtener el SQL de la DW dk_comisiones_un_periodo, para ver de ejecutarlo y ver que pasa, si para vos es esa la que se ejecuta en la operación asi00001 (para mi era otra …).

Otra cosa que hice recien fue ejecutar una actualización de las estadísticas de la base.

Lo único que se me ocurre es que como ese motor tiene un dbspace jodido (era el dbspace de producción anterior), que esté influyendo eso, aunque no tiene lógica.

Jodido significa: no puedo renombrar ni dropear la base que tiene, no puedo sacar ese dbspace tampoco. No me deja!! Estamos trabajando todo en otro dbspace, que era el de pruebas.

Fijate en el Onstat, yo voy a ver de ejecutar el SQL. A ver si podemos encontrar el problema …

Saludos


onstat_a.txt (885 KB)

Alejandro:

El select de esa DW que vos decís parece ser:

SELECT dba.sga_comisiones.unidad_academica,
dba.sga_comisiones.comision,
dba.sga_comisiones.nombre,
dba.sga_comisiones.materia,
dba.sga_comisiones.anio_academico,
dba.sga_comisiones.periodo_lectivo,
dba.sga_materias.nombre,
dba.sga_materias.nombre_reducido,
dba.sga_comisiones.sede
FROM dba.sga_comisiones,
dba.sga_materias,
dba.sga_periodos_lect
WHERE dba.sga_comisiones.unidad_academica = :ua and
dba.sga_comisiones.anio_academico = :anio and
dba.sga_comisiones.periodo_lectivo = :periodo and
( dba.sga_comisiones.materia = :materia OR :materia = ‘’ ) and
dba.sga_materias.unidad_academica = dba.sga_comisiones.unidad_academica and
dba.sga_materias.materia = dba.sga_comisiones.materia and
dba.sga_periodos_lect.periodo_lectivo = sga_comisiones.periodo_lectivo and
dba.sga_periodos_lect.anio_academico = dba.sga_comisiones.anio_academico and
dba.sga_periodos_lect.fecha_inactivacion >= TODAY and
dba.sga_comisiones.comision NOT IN (SELECT sga_subcomisiones.comision
FROM sga_subcomisiones) and
dba.sga_comisiones.sede IN (SELECT dba.sga_sedes_usuario.sede FROM dba.sga_sedes_usuario
WHERE dba.sga_sedes_usuario.usuario = USER)

ORDER BY 4, 2

Yo ejecuté:

SELECT dba.sga_comisiones.unidad_academica,
dba.sga_comisiones.comision,
dba.sga_comisiones.nombre,
dba.sga_comisiones.materia,
dba.sga_comisiones.anio_academico,
dba.sga_comisiones.periodo_lectivo,
dba.sga_materias.nombre,
dba.sga_materias.nombre_reducido,
dba.sga_comisiones.sede
FROM dba.sga_comisiones,
dba.sga_materias,
dba.sga_periodos_lect
WHERE dba.sga_comisiones.unidad_academica = “EST” and
dba.sga_comisiones.anio_academico = 2017 and
dba.sga_comisiones.periodo_lectivo = “Anual” and
( dba.sga_comisiones.materia = “503R” ) and
dba.sga_materias.unidad_academica = dba.sga_comisiones.unidad_academica and
dba.sga_materias.materia = dba.sga_comisiones.materia and
dba.sga_periodos_lect.periodo_lectivo = sga_comisiones.periodo_lectivo and
dba.sga_periodos_lect.anio_academico = dba.sga_comisiones.anio_academico and
dba.sga_periodos_lect.fecha_inactivacion >= TODAY and
dba.sga_comisiones.comision NOT IN (SELECT sga_subcomisiones.comision
FROM sga_subcomisiones) and
dba.sga_comisiones.sede IN (SELECT dba.sga_sedes_usuario.sede
FROM dba.sga_sedes_usuario
WHERE dba.sga_sedes_usuario.usuario = “estpalau”)
ORDER BY 4, 2

Y no me trajo ninguna comisión!!! Y ahí al ejecutar sin el " dba.sga_periodos_lect.fecha_inactivacion >= TODAY " me trajo la comisión en cuestión. Ahí me di cuenta!!

Fui a los archivos de log y confirmé mi suposición: estaba mal la fecha de inactivación del período y cada 2 o 3 días me la modificaban, ampliandola hasta el día de la fecha!!! Les voy a cortar los dedos a los usuarios!!! jajaja!! Como hacen eso?? Son de terror!!!

Saludos y graciaS!!!

Gustavo

Pero !!! Asi es dificil poder encontrar el problema. Se suponía que no había cambios…
Gracias por avisar y haber usado los logs para ver si encontrabas algo alli!

Y si … nunca se me ocurrió que me estarían modificando un registro de esa tabla!!!

Saludos!