Creación de los SP: InsertarEmpleado y EliminarEmpleado

 Hora de inicio: 7:00 a.m. 

Hora de finalización: 9:30 a.m.

Horas trabajadas: 2 h 30 min

Con la estructura de tablas creada en Azure SQL Database, el siguiente paso era implementar los primeros stored procedures que formarían la base de la capa de datos de la aplicación. 

Ya con la tarea 1 y 2 habíamos aprendido bien como tratar con los SPs, y en la tarea 2 ya habíamos realizado SPs de inserción y eliminicación de empleados. Por lo que esto no fue complicado, fue solo adaptar los SPs a lo que requeríamos aquí.

Actividades Realizadas

7:00 a.m - 8:00 a.m

Implementación de InsertarEmpleado

Este SP permite insertar un nuevo empleado en la tabla Empleado. Se tomó como base el SP de la tarea angerior, pero adaptándola según correcciones que el profesor nos dio en la revisión anterior.

El flujo del SP es:

Validación de documento de identidad duplicado: Se verifica que no exista otro empleado activo con el mismo documento. Si existe, se asigna el código de error 50004 y se registra un evento de tipo 5 ("Inserción no exitosa") con la descripción del error.

Validación de nombre duplicado: Se verifica que no exista otro empleado activo con el mismo nombre. Si existe, se asigna el código de error 50005 y se registra un evento tipo 5 con la descripción del error.

Validación de username duplicado: se verifica que no exista otro usuario con el mismo username.

Inserción: Si las validaciones pasan se abre una transacción en la que se ingresan datos en la tablas usuario, empleado, usuarioEmpleado,etc.

Registro de bitácora: Si la inserción fue exitosa, se registra un evento de tipo 6 ("Inserción exitosa") con los datos del empleado insertado.

Un detalle importante: las validaciones de duplicados se hacen antes de abrir la transacción. La transacción envuelve solo el INSERT y COMMIT, como indicó el profe. Esto es eficiente porque si una validación falla, no hay necesidad de abrir una transacción que luego se revertiría. 

Errores encontrados

Error : La bitácora devuelve su propio resultset antes del resultCode

Al ejecutar Login desde Python, se obtenía un error indicando que pyodbc estaba leyendo un resultset inesperado o vacío.

Causa: El SP de Login llama a RegistrarBitacora en varias ocasiones. Cada vez que se llama un SP desde dentro de otro SP, ese SP devuelve su propio resultset. Entonces se recibían varios resulsets.

Sin saber cuál resultset contiene el resultCode, pyodbc termina leyendo uno de los resultsets de la bitácora que puede no tener las columnas esperadas.

Solución Encontrada: En Python, implementar un patrón de lectura que itera sobre todos los resultsets hasta encontrar el correcto.

Este patrón itera sobre todos los resultsets con cursor.nextset(), y en cada iteración verifica las columnas del resultset actual usando cursor.description. Cuando encuentra una columna llamada resultCode, sabe que encontró el resultset del SP principal y lee los datos. Luego rompe el ciclo con break.

8:00 a.m - 9:30 a.m

Implementación de EliminarEmpleado

Este Sp lo construí usando como base el EliminarEmpleado de la tarea anterior. Resultó  bastante sencillo una vez analicé como funcionaba el viejo SP.

Primero se hace un preproceso:

Esto para evitar en una transacción que no se va a completar. Como es un borrado lógico luego simplemente se hace un update en el que se coloca al Empleado como inactivo (borrado lógico).

Forma de Trabajo en Equipo

La comunicación fue mediante whatsApp. Ya nos habíamos dividido el trabajo anteriormente.

Referencias consultadas

• Microsoft Docs: DATEADD function: https://learn.microsoft.com/en-us/sql/t-sql/functions/dateadd-transact-sql
• Microsoft Docs :Transactions in SQL Server: https://learn.microsoft.com/en-us/sql/t-sql/language-elements/transactions-transact-sql
• pyodbc Documentation: Reading multiple result sets: https://github.com/mkleehammer/pyodbc/wiki
• Flask Documentation:Sessions: https://flask.palletsprojects.com/en/stable/
• Tarea 2 de BD1