Ir al contenido principal

Entradas

18. Resolución de problemas y finalización del desarrollo del trigger

Día: 29/05/2023 Desde: 2:30 pm / Hasta: 4:43 pm Tiempo transcurrido: 2 horas 13 minutos Al final se decidió aplicar un esquema de ambas ideas que teníamos del trigger, para dejarlo como una estructura tentativa y cuando ya tuviéramos una versión más avanzada del proyecto poder decidir cuál aplicar y cuál no. El día comenzó con una revisión detallada de los problemas que habían surgido el día anterior. El equipo se centró en la configuración del trigger, que no respondía correctamente a los eventos de inicio de sesión. Después de una cuidadosa revisión del código y de las pruebas realizadas, identificaron que el problema residía en la lógica de verificación de las credenciales de los usuarios. Decidimos revisar documentación y otros recursos en internet sobre la creación de triggers en SQL Server. A través de esta investigación, descubrieron que estaban utilizando incorrectamente las tablas a las cuales el trigger estaba modificando. Estas tablas capturan los datos de la fila modificada...

17. Inicio del desarrollo del trigger y primeros problemas técnicos

Día: 25/05/2023 Desde: 10:10 am / Hasta: 12:24 pm Tiempo transcurrido: 2 horas 14 minutos Los triggers son una parte esencial de cualquier sistema de base de datos, ya que entendimos cómo permiten realizar acciones automáticas en respuesta a ciertos eventos en la base de datos. En este caso, el equipo necesitaba desarrollar un trigger que respondiera a los eventos de login de los usuarios o por otro lado aplicarlo a la nueva implementación del proyecto, las Nuevas Tarjetas. Inicialmente se diseñó la idea del trigger utilizado en la autenticación de los usuarios, se decidió que el trigger debería verificar si el nombre de usuario y la contraseña ingresados por el usuario son válidos y, en caso de serlo, determinar si el usuario es un administrador o un tarjetahabiente. Este proceso requería una cuidadosa planificación y diseño, ya que cualquier error en esta etapa podría tener graves consecuencias para la seguridad y la funcionalidad del sistema. A medida que el equipo comenzó a impleme...

16. Finalización del Diseño Preliminar de la Capa Lógica y Pruebas Iniciales

Día: 24/05/2023 Desde: 3:00 pm / Hasta: 5:15 pm Tiempo transcurrido: 2 horas 15 minutos Para esta fecha ya teníamos el modelo preliminar de la capa lógica. Este diseño preliminar incluía la implementación de la lógica de negocio en C# y ASP.NET, la creación de procedimientos almacenados para la manipulación de datos y la configuración de la interfaz de usuario para interactuar con la base de datos. Se comenzó la sesión con una revisión del código, identificando áreas que requerían mejoras y ajustes. Se realizaron cambios en el código para mejorar la eficiencia y la legibilidad, y se realizaron pruebas exhaustivas para asegurar que todos los componentes funcionaran como se esperaba. Durante este proceso, el equipo se encontró con varios desafíos, como la necesidad de solucionar errores menores que surgieron durante las pruebas. A pesar de estos desafíos, el equipo trabajó para resolver estos problemas. Nos apoyamos en la experiencia previa en el desarrollo de aplicaciones web para tomar...

15. Continuación del Diseño de la Capa Lógica y Procedimientos Almacenados para Visualizar Información

Día: 23/05/2023 Desde: 9:15 am / Hasta: 11:31 am Tiempo transcurrido: 2 horas 16 minutos Para esta sesión se continuó con la capa lógica y la estrategia fue basarse en el diseño que se había utilizado para una tarea anterior, lo que permitió reutilizar una cantidad significativa de código y acelerar el proceso de desarrollo. Se copió el código original en C# y se cambió el nombre del proyecto para reutilizar los archivos Login.aspx, MasterPage.aspx y Select.aspx. Obviamente a partir de estos archivos se hicieron cambios variados, ya que el nuevo proyecto cuenta con funcionalidades muy distintas (así como se mencionó en entradas anteriores, como la eliminación de los botones, etc). En este caso, el objetivo era verificar si el usuario es un administrador o un titular de tarjeta y mostrar las tarjetas y estados de cuenta correspondientes. Para lograr esto, se reutilizó el diseño de la página de inicio para el inicio de sesión y la verificación del usuario. Aunque este enfoque permitió un...

14. Implementación de SPs para operaciones de mantenimiento y consulta

Día: 21/05/2023 Desde: 2:40 pm / Hasta: 4:57 pm Tiempo transcurrido: 2 horas 17 minutos Esta etapa era esencial para garantizar que el sistema pudiera interactuar de manera efectiva con la base de datos, permitiendo la manipulación y recuperación de datos de manera eficiente. El primer paso fue identificar las operaciones de mantenimiento y consulta que requerían SPs. Estas operaciones incluían tareas como la actualización de registros y la realización de consultas complejas para generar informes. Una vez identificadas estas operaciones con respecto al enunciado, comenzamos a diseñar los scripts que por ejemplo iban a servir para hacer las iteraciones de cuentas que procesaran cada movimiento propuesto en el XML. La implementación de los SPs presentó varios desafíos. Por ejemplo, el equipo tuvo que encontrar formas de optimizar las consultas para garantizar que se ejecutaran de manera eficiente, incluso cuando se trataba de grandes volúmenes de datos. También se tuvieron que implementa...

13. Desarrollo de SPs para la simulación de proceso en lote de las operaciones

Día: 19/05/2023 Desde: 11:00 am / Hasta: 1:18 pm Tiempo transcurrido: 2 horas 18 minutos En esta sesión se continuó el desarrollo de los Procedimientos Almacenados (SPs) para la simulación de procesos en lote. Esta tarea era crucial para el funcionamiento del sistema, ya que permitiría la ejecución de operaciones en grandes volúmenes de datos de manera eficiente. Se ocupaba para procesar desde la obtención de datos del XML de operaciones hasta la lógica interna del proyecto. El primer paso fue definir claramente los requisitos de estos SPs. Además, estos SPs debían ser capaces de manejar errores y excepciones de manera adecuada para garantizar la integridad de los datos. Una vez que se definieron los requisitos, se comenzó a realizar el script de procesamiento teniendo en cuenta el orden en que debían ir los procesos, en algunos de estos casos se planearon SP para modular el código, de igual forma triggers y vistas. Todo esto se haría en otras sesiones. Durante el desarrollo, el equipo...

12. Dificultades con la implementación de los SPs

Día: 17/05/2023 Desde: 3:15 pm / Hasta: 5:34 pm Tiempo transcurrido: 2 horas 19 minutos Se comenzó la sesión con la necesidad de crear un procedimiento almacenado (Stored Procedure, SP) para manejar el inicio de sesión del usuario en la aplicación. El equipo entendió que este SP sería crucial para la seguridad y funcionalidad de la aplicación, ya que permitiría verificar la identidad del usuario y determinar su nivel de acceso. El equipo comenzó a trabajar en el SP, que se llamaría desde la capa lógica en la página .NET llamada PageLogin.aspx. Este SP recibiría tres parámetros: el nombre del usuario, la contraseña y un parámetro de salida para el código de resultado de errores, inicializado en cero. El SP verificaría si el nombre y la contraseña proporcionados por el usuario son válidos y, si es así, determinaría si el usuario es un administrador o un titular de tarjeta. A medida que el equipo avanzaba en la creación del SP, surgieron algunas complicaciones. La lógica para verificar la...