Creación de tablas: TipoEvento, BitacoraEvento, DBError y Error

Fecha: viernes 17 de abril de 2026

Hora de inicio: 10:00 a.m.

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

Horas trabajadas: 1 h 10 min

El plan para esta sesión era crear las tablas que me correspondían según la división de trabajo que Johana y yo definimos por WhatsApp. Ella se encargaría de Puesto, Empleado, TipoMovimiento, Movimiento y Usuario; yo de TipoEvento, BitacoraEvento, DBError y Error. Nos coordinamos para trabajar en paralelo y así avanzar más rápido.

Actividades realizadas

10:00 a.m. – 10:25 a.m. — Problema con “USE BDTarea2”

Lo primero que hice fue abrir el script de tablas en SSMS, conectada al servidor en Azure. Al intentar ejecutarlo, me apareció un error que no esperaba, relacionado con la línea “USE BDTarea2” al inicio del script. Nunca había tenido ese problema antes, así que tuve que investigar.

Después de buscar, entendí que se debía a que en Azure SQL Database, a diferencia de una instancia local de SQL Server, no se puede usar “USE [NombreBD]” dentro de un script porque ya se establece la base de datos activa directamente en la cadena de conexión desde SSMS. Intentar cambiarlo con dicha sentencia genera un error porque Azure no lo permite de esa forma en el contexto de SQL Database (PaaS). La solución fue simplemente eliminar esa línea del script.

La moraleja es que Azure SQL Database tiene algunas diferencias con respecto a una instancia local de SQL Server que no son obvias al principio, y este fue el primer encontronazo con una de ellas.

Referencia:

En Azure SQL Database, el parámetro de base de datos solo puede hacer referencia a la base de datos actual. Si se proporciona una base de datos distinta de la base de datos actual, la USE instrucción no cambia entre bases de datos y se devuelve el código de error 40508. Para cambiar de base de datos, debe conectarse directamente a la base de datos. La USE instrucción se marca como no aplicable a Azure SQL Database en la parte superior de esta página, ya que aunque puede tener la USE instrucción en un lote, no hace nada (Microsoft).

10:25 a.m. – 11:00 a.m. — Creación de las tablas

Con eso resuelto, procedí a crear mis cuatro tablas. La lógica de cada una fue la siguiente:

TipoEvento: tabla catálogo sencilla. El id no es IDENTITY porque, según las indicaciones de la tarea, los catálogos traen el id definido desde el XML para garantizar que todos los equipos tengan los mismos ids.

BitacoraEvento: esta fue la más interesante de definir porque tiene dos llaves foráneas: una hacia TipoEvento y otra hacia Usuario. Nunca había trabajado con FOREIGN KEY de forma explícita en un script, así que antes de escribir el código me detuve a investigar la sintaxis correcta (documentación oficial de Microsoft) y a entender bien las relaciones entre las tablas.

Lo que aprendí es que el CONSTRAINT se define dentro del CREATE TABLE con la cláusula FOREIGN KEY ... REFERENCES, y que es importante que la tabla referenciada ya exista en la base de datos antes de crear la que tiene la llave foránea. Por eso TipoEvento y Usuario tenían que estar creadas primero. En nuestro caso, Johana ya había hecho commit de sus tablas (incluyendo Usuario), así que no hubo problema de dependencias.

DBError: tabla para registrar errores técnicos capturados en los bloques CATCH de los procedimientos almacenados. Todos sus campos son opcionales (sin NOT NULL) porque dependiendo del error, no todos los datos pueden estar disponibles al momento de registrarlo.

Error: tabla catálogo de mensajes de error. Tiene un campo Codigo separado del id porque el código de error es el que se retorna desde los SPs y se consulta desde la capa lógica, no el id interno de la tabla.

11:00 a.m. – 11:10 a.m. — Ajustes de consistencia en el script

Antes de hacer el commit, revisé el script completo y noté algunas inconsistencias menores con el código que ya había subido Johana: diferencias de indentación y algunas longitudes de VARCHAR que no coincidían con los campos equivalentes en mis tablas. Los ajusté para que el script quedara uniforme y consistente con los estándares de codificación del curso.

Forma de trabajo del equipo

Johana y yo nos coordinamos por WhatsApp desde el inicio de la mañana para repartirnos las tablas y arrancar en paralelo. Ella hizo su commit primero; yo terminé con el mío a las 11:10 a.m. una vez que tuve todo listo y revisado.

Referencias:

USE (Transact-SQL)

Primary and foreign key constraints

Create foreign key relationships

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