Implementación de los SP: Listar Movimientos y Logout

Fecha: 18 de abril 2026

Hora de inicio: 6:00 p.m. 

Hora de finalización: 8:00 p.m.

Horas trabajadas: 2h

Después de implementar los SPs de Login e InsertarEmpleado, el siguiente paso era completar los SPs necesarios para las funcionalidades de consulta de movimientos y cierre de sesión. Este trabajo fue más sencillo dado que ambos SP son bastante más simples que los creados más temprano.

Actividades realizadas

6:00 p.m. - 7:20 p.m.

Implementación de ListarMovimientos

Este SP es uno de los más importantes en términos de funcionalidad de negocio, ya que permite a los usuarios consultar el historial de movimientos (ganancias y disfrutes de vacaciones) de un empleado específico. A diferencia de SPs anteriores que devuelven un solo resultset, ListarMovimientos devuelve dos resultsets: primero los datos básicos del empleado, y luego la lista de todos sus movimientos. También es improtante notar que en esta caso no hubo registro en bitácora porque en el enunciado no había un evento relacionado exactamente con esto.

El flujo del SP es:

Primer SELECT - datos del empleado: Se consulta la tabla Empleado filtrando por id y verificando que sea un empeado activo. Se devuelven tres columnas.



Segundo SELECT- lista de movimientos: Se consulta la tabla Movimiento con dos INNER JOINs:

JOIN a TipoMovimieno para obtener el nombre del tipo de movimiento (ej: "Venta de vacaciones", "Disfrute de vacaciones")

JOIN a Usuario  para obtener el username de la persona que registró el movimiento.

El resultado se ordena por fecha DESC (fechas más recientes primero), de modo que el usuario ve el historial del más nuevo al más antiguo.


7:20 p.m. - 8:00 p.m.

Implementación de Logout

Este SP es el más simple del proyecto. Su única función es registrar en BitacoraEvento que el usuario cerró sesión. A diferencia de otros SPs, no hya lógica compleja.

El flujo es:

Recibe el id del usuario (que viene de session [id_usuario] en Flask) y la IP del cliente.

Llama a RegistrarBitacora con evento tipo 4 y una descripción vacía (ya que logout no requiere detalles adicionales).



Una observación: no se valida que el usuario exista antes de hacer logout. Esto porque el id viene de la sesión de Flask que solo se crea después de un login exitoso, por lo que el usuario ya fue validado en ese momento.

Errores encontrados

Error 1: Navegación entre múltiples resultsets en pyodbc con ListarMovimientos

Descripción: Al ejecutar  ListarMoviemientos desde Python, pyodbc devolvía datos pero era difícil saber cuál era el primer resultset, cuál el segundo y cuál el resultcode

Causa: SQL Server devuelve tres resultsets en orden:

  1. Los datos del empleado (1 fila)
  2. Los movimientos del empleado (N filas)
  3. El SELECT @outresultCode (1 fila)

Sin una estrategia clara de navegación, el código Python podría leer los datos en el orden incorrecto o intentar aplicar fetchcall en un resultset que solo tiene una fila.

Solución: Usar cursor.next() explícitamente para navegar entre resultsets en orden:



Este patrón es más simple que el While True usado en Login (donde hay múltiples llamadas a bitácora intercaladas), ya que aquí sabemos exactamente cuántos resultsets hay y en qué orden vienen.

Forma de trabajo del equipo

Nos comunicamos por medio de WhatsApp y Teams. VB avanzó en paralelo con sus propios SPs.

Buenas prácticas descubiertas

  • Los SPs de lectura pura (SELECT sin INSERT/UPDATE/DELETE) pueden ser más simples. No necesitan transacciones, no necesitan registrar en bitácora si no está definido en los requerimientos, y pueden enfocarse puramente en devolver datos.
  • Cuando un SP devuelve múltiples resultsets, la navegación en Python debe ser explícita. 
  • Los JOINs permiten obtener datos de múltiples tablas en una sola consulta. En ListarMovimientos, los JOINs a TipoMovimeinto y Usuario evitaron tener que hacer tres consultas separadas.

Referencias consultadas

Comentarios

Publicar un comentario

Entradas más populares de este blog

Creación del SP de Cargar Datos

Fecha:  20 de abril Hora de inicio: 9:00 a.m.  Hora de finalización: 12:00 p.m. Hora de inicio: 1:00 p.m.  Hora de finalización: 4:00 p.m. Horas trabajadas: 6h Con las tablas ya creadas en la base de datos, el siguiente paso era poblarlas con los datos de prueba provistos por el equipo del profesor. Para esto, se debía implementar el script para la carga de datos, que lo hicimos como SP, que recibe el contenido de un archivo XML y lo procesa directamente en SQL Server. Actividades realizadas 9:00 a.m. - 12:00 p.m. Antes de escribir el SP, fue necesario investigar cómo SQL Server maneja archivos XML de forma nativa, ya que el profesor indicó en su momento que no debíasmos hacerlo con un parser. Los conceptos investigados fueron:  nodes () y value() : funciones nativas de SQL Server para procesar XML. nodes() navega la estructura del documento y devuelve una fila por cada nodo encontrado — funciona como un recorrido sobre los elementos. value() extrae el v...
Leer más

Implementación de funcionalidades: Editar Empleado y Eliminar Empleado

Imagen
Fecha: sábado 25 de abril de 2026 Hora de inicio: 9:30 a.m. Hora de finalización: 5:38 p.m. Horas trabajadas:  4 h 41 min El plan para esta sesión era implementar las funcionalidades completas de editar y eliminar empleado. Fue la sesión más larga del proyecto hasta ahora, con bastante trabajo tanto en capa lógica como en presentación. Actividades realizadas 9:30 a.m. – 10:35 a.m. — Función actualizar_empleado (modelo) Empecé por la función en Python que conecta con el SP ActualizarEmpleado. La estructura es similar a las funciones que ya había hecho: abre la conexión, ejecuta el SP con cursor.execute, lee el resultset con el código de resultado y cierra la conexión en el finally. Un detalle importante en esta función es el conn.commit() después del fetchone. Como ActualizarEmpleado hace un UPDATE dentro de una transacción, es necesario confirmar el cambio desde la capa Python también, de lo contrario la modificación no persiste en la base de datos. Esto ya lo ha...
Leer más

Implementación de funcionalidad: Consultar Empleado

Imagen
Fecha: viernes 24 de abril de 2026 Hora de inicio: 2:30 p.m. Hora de finalización: 7:45 p.m. Horas trabajadas:  3 h 02 min El plan para esta sesión era implementar la funcionalidad completa de consultar empleado: la función en la capa lógica, el controlador y la vista. Johana ya había terminado su parte de capa lógica y presentación días antes, así que yo había esperado a que estuviera lista para arrancar con la mía, tal como lo acordamos. Actividades realizadas 2:30 p.m. – 3:20 p.m. — Función consultar_empleado (capa lógica) Comencé escribiendo la función consultar_empleado en Python. Esto era bastante similar a lo que hice en la tarea 1, así que no partí desde cero: repasé el código de la tarea anterior para refrescar cómo se hacían las llamadas a SPs con pyodbc y cómo se manejaban los resultsets. La función abre la conexión, ejecuta el SP con cursor.execute, lee el primer resultset con cursor.fetchone para obtener los datos del empleado, y luego llama a cursor.nextset() para ...
Leer más