Ir al contenido principal

Entradas

Mostrando entradas de mayo, 2023

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...

11. Inicio del Procedimiento Almacenado para la Visualización de Cuentas

Día: 16/05/2023 Desde: 9:30 am / Hasta: 11:50 am Tiempo transcurrido: 2 horas 20 minutos El siguiente paso en el desarrollo del proyecto fue la creación de un Store Procedure para mostrar los movimientos de las cuentas. Este procedimiento sería crucial para permitir a los usuarios ver los detalles de sus transacciones y el estado de sus cuentas. El equipo decidió que este procedimiento almacenado recibiría como parámetro el nombre del usuario y un bit en 1 o 0 que indica si el usuario es administrador. Para este procedimiento, se obtendría la información de la cuenta del usuario mapeando el nombre ingresado del usuario desde el login a través de un INNER JOIN de la tabla tarjetaHabiente con la tabla tarjetafisica y se procedería a mostrar todos los movimientos del estado o sub-estado de cuenta relacionado con la cuenta del usuario. Se trabajó este procedimiento almacenado durante esta sesión, y aunque hubo algunos desafíos en el camino, lograron hacer progresos significativos.

10. Inicio del desarrollo de los procedimientos almacenados (SPs)

Día: 14/05/2023 Desde: 2:00 pm / Hasta: 4:21 pm Tiempo transcurrido: 2 horas 21 minutos Con el procedimiento de inicio de sesión completado, el equipo se movió hacia la creación de otro Store Procedure, esta vez para mostrar los grids de las cuentas de la base de datos y los movimientos asociados al usuario que ha ingresado desde la página de login. Este procedimiento almacenado también se creó en MSSQL y recibió como parámetro el nombre del usuario y un bit en 1 o 0 que indica si el usuario es administrador. El equipo pasó gran parte del día trabajando en este procedimiento, asegurándose de que la lógica de la base de datos estuviera correctamente implementada y de que los datos se mostraran correctamente en la interfaz de usuario.

9. Implementación del Procedimiento Almacenado para la Autenticación de Usuarios

Día: 13/05/2023 Desde: 10:20 am / Hasta: 12:42 pm Tiempo transcurrido: 2 horas 22 minutos Comenzamos el día con la tarea de crear un Procedimiento Almacenado (Store Procedure) para manejar el inicio de sesión del usuario. Este procedimiento sería crucial para la funcionalidad de la aplicación, ya que determinaría si el nombre y la contraseña ingresados por el usuario son válidos y si el usuario es un administrador o un titular de tarjeta. El equipo decidió crear el Store Procedure en SQL Server Management Studio (MSSQL). El procedimiento recibiría tres parámetros: el nombre del usuario ingresado, la contraseña y el parámetro outResultCode para el resultado de errores, el cual estaría inicializado en cero. El equipo dedicó una cantidad significativa de tiempo a la programación en SQL Server de este procedimiento almacenado, ya que ya tenían diseñada la página para hacer login desde la tarea anterior. A pesar de algunos desafíos iniciales, el equipo logró crear un procedimiento que funci...

8. Rediseño de la Interfaz de Usuario y Creación de Nuevas Páginas

Día: 12/05/2023 Desde: 3:30 pm / Hasta: 5:52 pm Tiempo transcurrido: 2 horas 22 minutos Continuamos trabajando en el diseño de la capa lógica, haciendo los cambios necesarios que pide esta tarea para la interfaz de usuario. Se eliminaron los botones del grid principal de la tarea anterior, pues ahora no se necesita que el usuario inserte o filtre contenidos de las tablas de la BD. Además, se eliminó la página para insertar, por estos mismos motivos que se han mencionado, y más bien se han agregado nuevas páginas como SelectCuentas.aspx y SelectMovimientos.aspx. Estas nuevas páginas creadas serán redireccionadas desde la página de LogIn dependiendo si el usuario ingresado pertenece a unadministrador o a un TarjetaHabiente. En caso de que sea un usuario administrador, se enviará al usuario a SelectCuentas.aspx en donde se mostrarán las cuentas con sus tarjetas, tipos de cuenta y demás información relacionada con la cuenta de tarjeta de crédito. En cada fila de la respectiva cuenta se tie...

7. Inicio del Diseño de la Capa Lógica y Reutilización de Código

Día: 10/05/2023 Desde: 11:15 am / Hasta: 1:38 pm Tiempo transcurrido: 2 horas 23 minutos Con el script de llenado de catálogos completado, el equipo cambió su enfoque hacia el diseño de la capa lógica utilizando C# ASP.Net. Este sería un paso crucial en el desarrollo del proyecto, ya que la capa lógica es responsable de la funcionalidad principal de la aplicación. Se decidió basar el diseño de la capa lógica en el diseño que habían utilizado para una tarea anterior. 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. El objetivo era verificar si el usuario es administrador o un tarjetahabiente y mostrar las tarjetas y estados de cuenta respectivos. Nos centramos en el análisis, eliminación de ciertos bloques y cambios en alguno de los bloques del código que ya tenían hecho en C# desde la tarea anterior. Se dedicó una cantidad significativa de tiempo a la revisión y modificación del código para adap...

6. Resolución de problemas y finalización del script de llenado de catálogos

Día: 08/05/2023 Desde: 2:45 pm / Hasta: 5:09 pm Tiempo transcurrido: 2 horas 24 minutos La sesión comenzó con una revisión detallada de los problemas que habían surgido en la sesión anterior. Se identificaron problemas específicos con la implementación de los procedimientos almacenados y se discutieron posibles soluciones. Se decidió que se necesitaba una revisión más profunda del código SQL para identificar y corregir los errores. Se dedicó una cantidad significativa de tiempo a la depuración del código, con cada miembro del equipo revisando diferentes secciones del script. Se identificaron varios errores sutiles, como errores de sintaxis y problemas con la lógica de los procedimientos almacenados. Nos dimos cuenta de que algunos de los datos iniciales que se estaban utilizando para poblar las tablas no eran consistentes con las reglas de negocio definidas. Esto requería una revisión de los datos y ajustes para garantizar que los datos iniciales fueran correctos. Después de un esfuerz...

5. Problemas con la implementación del script de llenado de catálogos

Día: 06/05/2023 Desde: 9:00 am / Hasta: 11:23 am Tiempo transcurrido: 2 horas 23 minutos A medida que el equipo avanzaba en el desarrollo del script de llenado de catálogos, surgieron varios problemas. Se tuvieron dificultades para implementar los procedimientos almacenados en SQL Server, mientras que otros encontraron problemas al intentar poblar las tablas con los datos iniciales. El equipo se esforzó por resolver estos problemas. Se consultaron recursos en línea, se discutieron diferentes enfoques y se realizaron múltiples pruebas. A pesar de los desafíos, el equipo se mantuvo enfocado y trabajó en conjunto para encontrar soluciones. Al final del día, aunque no se resolvieron todos los problemas, se hizo un progreso significativo en el desarrollo del script de llenado de catálogos. Dejamos por ahora el proceso así, ya que entendemos cómo ese error es parte del desarrollo y se va trabajar en hacer pruebas parciales y dividir el códigos según las tablas y así identificar dónde puede e...

4. Inicio del desarrollo del script de llenado de catálogos

Día: 04/05/2023 Desde: 1:10 pm / Hasta: 3:36 pm Tiempo transcurrido: 2 horas 26 minutos Con la estructura de la base de datos establecida, el equipo se centró en el desarrollo del script de llenado de catálogos. Este script sería responsable de poblar las tablas de la base de datos con datos iniciales para su funcionamiento. El equipo decidió que el script debería ser flexible y fácil de modificar, para permitir cambios en los datos a medida que el proyecto avanzara. Se discutieron diferentes enfoques para la implementación del script, y se decidió utilizar procedimientos almacenados para maximizar la eficiencia y la seguridad. Sin embargo, la tarea no estuvo exenta de desafíos. La definición de los datos iniciales requería una comprensión clara de las reglas de negocio y de las necesidades de los usuarios finales.

3. Resolución de problemas técnicos y finalización de la estructura de la base de datos

Día: 02/05/2023 Desde: 3:20 pm / Hasta: 5:44 pm Tiempo transcurrido: 2 horas 24 minutos Se dedicó una cantidad significativa de tiempo a la depuración y a la revisión del código SQL, con el objetivo de resolver los problemas de configuración y las dificultades con las relaciones entre las tablas. Se consultaron diversas fuentes de información, incluyendo documentación en línea y foros de discusión, para encontrar soluciones a los problemas técnicos. Se realizaron pruebas exhaustivas y se ajustaron los detalles hasta que finalmente se logró una estructura de base de datos funcional y eficiente. Además, se presentó el modelo físico de la base de datos al profesor durante una consulta en clase. Tras una revisión detallada, el profesor dio su visto bueno, lo que reforzó la confianza del equipo en el trabajo realizado hasta ahora. A partir de ahora, teniendo el modelo físico terminado, podíamos enfocarnos en los distintos SP y en sí todas las funcionalidades que indicaba la lógica del proye...