Creación de procedimientos almacenados: ObtenerMensajeError y RegistrarBitacora

Fecha: sábado 18 de abril de 2026

Hora de inicio: 7:45 p.m.

Hora de finalización: 9:10 p.m.

Horas trabajadas: 1 h 25 min

El plan para esta sesión era implementar dos de los procedimientos almacenados que me correspondían y que eran prioritarios: ObtenerMensajeError y RegistrarBitacora. Acordé con Johana que yo me encargaba de ambos completamente y que los haría de primero ya que todas las funcionalidades los necesitan, tanto en capa de base de datos como en capa lógica. Era importante tenerlos listos cuanto antes para no bloquear el avance de las dos.

Actividades realizadas

7:45 p.m. – 8:10 p.m. — Investigación previa

Antes de escribir una sola línea de código, me puse a investigar las funciones del sistema que necesitaba para llenar la tabla DBError dentro del bloque CATCH. Sabía que tenía que capturar información del error (número, mensaje, línea, procedimiento, etc.), pero no conocía las funciones específicas de SQL Server para obtener esos datos.

Las funciones que tuve que investigar fueron:

  • ERROR_NUMBER(): retorna el número del error.
  • ERROR_STATE(): retorna el estado del error.
  • ERROR_SEVERITY(): retorna la severidad.
  • ERROR_LINE(): retorna la línea donde ocurrió el error.
  • ERROR_PROCEDURE(): retorna el nombre del SP donde ocurrió.
  • ERROR_MESSAGE(): retorna el mensaje descriptivo del error.
  • SUSER_NAME() / SUSER_SNAME(): retornan el nombre de inicio de sesión del usuario actual. Noté que en distintos ejemplos aparecían las dos versiones y tuve que investigar la diferencia: SUSER_NAME() acepta un parámetro opcional (el id del usuario), mientras que SUSER_SNAME() sin argumentos es equivalente, pero es la forma más común de verla en ejemplos de manejo de errores.

8:10 p.m. – 8:40 p.m. — SP: ObtenerMensajeError

Este SP recibe un código de error como parámetro y busca la descripción correspondiente en la tabla Error.

Después de crearlo lo probé con un EXEC desde SSMS pasándole un código que existía en la tabla y uno que no, para verificar que los dos casos funcionaran correctamente.

8:40 p.m. – 9:10 p.m. — SP: RegistrarBitacora

Este fue más directo de implementar una vez que tenía clara la estructura de BitacoraEvento. Recibe los cinco datos del evento (tipo, descripción, usuario, IP y timestamp) y los inserta en la tabla. Si el INSERT falla, el CATCH registra el error técnico en DBError.

Lo que me pareció importante destacar de este SP es que no recibe el timestamp con GETDATE() internamente, sino que lo recibe como parámetro (@inPostTime). Esto es intencional, pues el timestamp lo captura el SP que llama a RegistrarBitacora, no este SP en sí.

También lo probé con un EXEC básico para asegurarme de que insertara correctamente en BitacoraEvento y que no lanzara errores.

Forma de trabajo del equipo

Johana avanzó en paralelo con sus SPs (Login, Logout, ListarEmpleados e InsertarEmpleado). Nos mantuvimos en contacto por WhatsApp para coordinarnos, especialmente porque ella necesitaba que RegistrarBitacora estuviera disponible para poder llamarlo desde sus propios procedimientos. Mientras yo terminaba estos dos, ella fue avanzando en la lógica de los suyos.

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