Creación de ListarPuestos y ListarEmpleados


Hora de inicio: 8:00 a.m. 

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

Horas trabajadas: 3 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. 

En la Tarea 1 habíamos aprendido sobre cómo trabajar con SPs desde Python usando pyodbc. En esta tarea, el desafío era aplicar esos conocimientos de forma consistente a través de múltiples SPs más complejos, manteniendo el estándar que el profesor había indicado.


Actividades realizadas

10:00 a.m. - 1:30 p.m.

Se implementaron dos SPs iniciales (quitando CargarDatos):ListarEmpleados y ListarPuestos. Aunque ambos son operaciones de lectura relativamente simples (solo hacen SELECT), fueron fundamentales para establecer los patrones que se aplicarían en SPs más complejos como InsertarEmpleado y Login

Patrón 1: SET NOCOUNT ON

Desde la Tarea 1, ya habíamos descubierto que cuando un SP contiene operaciones como INSERT, UPDATE o DELETE, SQL Server internamente genera mensajes que dicen "X filas afectadas". Estos mensajes son información de control que normalmente el usuario no necesita ver, pero pyodbc los interpreta como resultsets válidos, causando que la lectura de resultados se desordene.

Por ejemplo, si un SP hace un INSERT y luego un SELECT, sin SET NOCOUNT ON, pyodbc recibe:

  1. Mensaje: "1 fila afectada" (interpretado como resultset)
  2. El recordset del SELECT
  3. El SELECT @resultCode

Sin SET NOCOUNT ON, pyodbc puede terminar leyendo el primero cuando quería el segundo, causando errores como "No results. Previous SQL was not a query".


BEGIN TRY/CATCH y manejo de errores

El profesor indicó explícitamente en la rúbrica que todo SP debe implementar manejo de errores usando BEGIN TRY/CATCH. La idea es que si algo falla en la ejecución del SP (por ejemplo, una violación de constraint, un timeout, un error de conversión de datos), el SP no simplemente falle, sino que capture ese error, lo registre en la tabla DBERROR.

En ListarEmpleados, aunque es una consulta simple, el patrón se implementó igual:



Patrón 3: Variables internas y devolución de resultCode

Con la la Tarea 1 descubrimos que pyodbc no maneja parámetros OUTPUT de forma directa. Por ello se decidió declarar como variable interna las varibales de retorno.

Implementación específica de cada SP

ListarEmplados es el SP que devuelve la lista de todos los empleados activos, ordenados por nombre (R2) . El profe indicó que esta lista se usaría en la página principal de la aplicación con un filtro (por nombre o cédula), el filtro también se implementó en el SP.


ListarPuestos es más simple aún: solo devuelve los puestos disponibles, ya que se necesita para un dropdown en el formulario de inserción de empleados. El orden es alfabético por el nombre del puesto, como indicó el profesor.

Se probaron ambos SPs en SSMS ejecutándolos directamente para verificar que devolvieran los datos esperados. Luego se crearon scripts de prueba en Python para validar que pyodbc pudiera leerlos correctamente sin errores de parsing.

Errores encontrados

No hubo errores significativos en esta etapa, ya que los patrones clave habían sido descubiertos, documentados y ampliamente probados en la Tarea 1. La implementación de estos dos SPs fue más bien un ejercicio de aplicar esos patrones conocidos de forma consistente y disciplinada, consolidando el estándar que se mantendría en SPs posteriores más complejos como InsertarEmpleado, Login y CargarDatos.

Sin embargo, fue importante recordar y aplicar nuevamente:

  • No olvidar SET NOCOUNT ON (sino fallaría en SPs posteriores con INSERT/UPDATE)
  • Siempre usar el patrón BEGIN TRY/CATCH, incluso en SPs simples
  • Devolver resultCode mediante SELECT, no mediante OUTPUT parameters

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