Creación de procedimientos almacenados: ConsultarEmpleado, EliminarEmpleado y RegistrarIntentoEliminarEmpleado

Fecha: domingo 19 de abril de 2026

Hora de inicio: 8:45 a.m.

Hora de finalización: 1:42 p.m.

Horas trabajadas: 1 h 57 min

El plan para esta sesión era implementar tres de los SPs que me correspondían para el módulo de empleados: consultar, eliminar y registrar el intento de eliminación. Fue una sesión larga pero con pausas, no trabajé de corrido.

Actividades realizadas

8:45 a.m. – 9:25 a.m. — SP: ConsultarEmpleado

Antes de escribir el código, me detuve a investigar varias cosas que necesitaba para este SP y que no había usado antes. La principal fue INNER JOIN, que aparece en el SELECT para traer el nombre del puesto desde la tabla Puesto relacionándola con Empleado a través de IdPuesto. Sabía conceptualmente qué era un join, pero nunca lo había escrito en un SP, así que busqué ejemplos y me aseguré de entender la sintaxis antes de continuar.

Otra cosa que tuve que investigar fue cómo construir el string de descripción para la bitácora. Para esto, combiné CAST para convertir valores numéricos a texto e ISNULL para evitar que la concatenación falle si algún campo viene nulo.

Una vez terminado lo probé desde SSMS para verificar ambos casos: un empleado que existe y uno que no.

10:40 a.m. – 11:31 a.m. — SP: EliminarEmpleado

Este SP lo construí usando ConsultarEmpleado como base para el borrado lógico. El tiempo entre commits se explica porque hubo pausas y porque tuve que investigar varias cosas nuevas para mí.

Lo primero fue entender BEGIN TRANSACTION y COMMIT TRANSACTION. Nunca los había usado y era la primera vez que escribía una transacción. Lo que aprendí es que envolver el UPDATE dentro de una transacción garantiza que si algo falla en medio de la operación, el cambio no quede a medias.

Lo segundo fue el UPDATE en sí, también nuevo para mí en el contexto de un SP.

Lo tercero, y lo que más me costó entender, fue XACT_STATE() en el bloque CATCH. Lo vi en un recurso que encontré y lo implementé. Lo que hace es verificar el estado de la transacción activa antes de intentar hacer el ROLLBACK, si XACT_STATE() es distinto de cero, significa que hay una transacción activa (ya sea confirmable o no confirmable), y solo entonces se ejecuta el ROLLBACK.

También tuve que investigar ROLLBACK TRANSACTION, que va de la mano con lo anterior.

Una vez terminado lo probé, verificando el borrado de un empleado existente y el intento sobre uno que no existía.

1:15 a.m. – 1:42 p.m. — SP: RegistrarIntentoEliminarEmpleado

Este SP no estaba en el plan original, surgió cuando analicé el requerimiento R7 de trazabilidad. El requerimiento indica que se debe registrar en bitácora el "intento de borrado", que corresponde al momento en que el sistema le muestra al usuario la alerta de confirmación, antes de que confirme o cancele. El problema es que ese evento ocurre en un momento diferente al borrado real, y mezclar ambas responsabilidades en EliminarEmpleado me parecía confuso. Terminé tomando la decisión de separarlo en un SP propio.

La estructura es similar a los anteriores, pues hace un SELECT para obtener los datos del empleado, construye la descripción de la bitácora con esos datos y llama a RegistrarBitacora con el tipo de evento 9 ("Intento de borrado"). Si el empleado no existe o ya está inactivo, simplemente no registra nada.

El tiempo entre el commit de EliminarEmpleado y este fue también por pausas, no porque el SP fuera especialmente complejo, ya tenía el patrón claro de los anteriores.

Lo probé para verificar que el registro en bitácora quedara correcto.

Forma de trabajo del equipo

Nos mantuvimos en contacto por WhatsApp para coordinarnos sobre el estado general del proyecto.

Referencias:

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