Creación de la base de datos en Azure

Fecha: jueves 16 de abril de 2026

Hora de inicio: 11:00 a.m.

Hora de finalización: 12:15 p.m.

Horas trabajadas: 1 h 15 min

El plan para esta sesión era crear la instancia de Azure y la base de datos. Antes de lanzarme a crearla, quería asegurarme de elegir la opción correcta, así que dediqué los primeros minutos a investigar.

Actividades realizadas

Lo primero fue registrarme en el portal de Azure usando el correo institucional. Consulté un par de videos para orientarme con la interfaz antes de tomar cualquier decisión.

Luego investigué qué opción de despliegue se adaptaba mejor a nuestro contexto. Las dos alternativas que evalué fueron:

  1. Máquina Virtual (VM) con SQL Server: ofrece más control, pero requiere mantener la VM encendida y configurar puertos y redes manualmente.
  2. Azure SQL Database (PaaS): servicio administrado, más sencillo y acceso remoto sin preocuparse por infraestructura.

Decidí usar Azure SQL Database (PaaS) porque es más práctico, tiene menor complejidad y no necesitamos el control adicional que da una VM.

Finalmente, procedí a crear la base de datos desde el portal de Azure.

Problema encontrado: Error de región (RequestDisallowedByAzure)

Al intentar crear la base de datos, el despliegue falló varias veces seguidas. El mensaje de error fue:

InvalidTemplateDeployment - Los recursos 'server-tarea2-bd1' y 'BDTarea2' fueron bloqueados por una política de Azure.

Intenté desplegar en East US, Brazil South, Central US y Mexico Central, pero en todos los casos la suscripción de estudiante lo impedía. El error indicaba que una política de la suscripción restringía las regiones disponibles para crear recursos.

Imagen1: Error "InvalidTemplateDeployment"

Solución

Cambié la región a Canada Central, que sí estaba permitida, y el despliegue se completó sin problemas. 

Con la base de datos creada, configuré el firewall, esto incluyó permitir que los servicios y recursos de Azure accedan al servidor y agregar reglas de firewall con las IPs públicas mías y de Johana.

Finalmente, ambas nos conectamos desde SSM. La conexión funcionó sin inconvenientes para las dos. La base de datos BDTarea2 quedó lista y accesible, así que el objetivo de la sesión se cumplió.

Forma de trabajo del equipo

Johana y yo nos coordinamos por WhatsApp. Mientras yo me encargaba de Azure, ella avanzó con la creación del repositorio y la estructura del proyecto en Flask, tal como lo definimos.

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