Primera reunion para comentar el pdf de la progra, repasamos todos los puntos y dividimos la carga, surgieron varias dudas que evacuaremos en los proximos dias, tambien creamos las nuevas tablas y comentamos que debiamos arreglar segun la revision de la progra pasada, ademas creamos un nuevo blog de bitacoras y esperamos ser mas profesionales en este
12/22/2020 Se intercambio el orden de los update e insert para que los insert estuviesen por encima de los updates. Se modifico la forma en la que se cuentan las operaciones de retiros de ATM y humano. Se sustituyeron algunos select por if. También se agrego el la tabla para el manejo de errores y el código para insertar en esta tabla.
12/23/2020 Se agregaron los TRANSACTION al SP de cerrado de estados de cuenta y al trigger para crear un estado de cuenta para, a este trigger también se le agrego el manejo de errores. Se utilizo el READ COMMITTED por estándar del curso.
BEGIN TRY SET TRANSACTION ISOLATION LEVEL READCOMMITED; BEGIN TRANSACTION nombreTransaccion Cosas por hacer COMMIT TRANSACTION nombreTransaccion; END TRY
BEGIN CATCH IF @@TRANCOUNT>0 ROLLBACK TRANSACTION nombreTransaccion; END CATCH
Isaac me dio un machote que tenia la informacion para insertar eventos, con estos adapte los cruds tanto de objetive account como de benefactor, para que al ser llamados funcione la insercion del evento y la accion a la que corresponde el evento, falta hacer pruebas para buscar fallos pero de primera mano no se ven errores
Tiempo Estimado(Mario): 1 hora Tiempo Estimado(Isaac): 40 min
@inId INT, @inUsuario INT BEGIN TRY DECLARE @XMLAntes XML, @XMLDespues XML
SET @XMLAntes = (SELECT B.[Id], B.[RelationshipId], B.[PersonId], B.[SavingsAccountId], B.[Name], B.[Percentage], B.[Condition], B.[InsertAt], B.[InsertBy], B.[InsertIn] FROM Benefactor AS B WHERE B.Id = @inId FOR XML AUTO)
BEGIN TRANSACTION updateBenefactor --UpdateBenefactor SET @XMLDespues = (SELECT B.[Id], B.[RelationshipId], B.[PersonId], B.[SavingsAccountId], B.[Name], B.[Percentage], B.[Condition], B.[InsertAt], B.[InsertBy], B.[InsertIn] FROM Benefactor AS B WHERE B.Id = @inId FOR XML AUTO)
CREATE PROCEDURE updateBenefactor( @inId INT, @inUsuario INT, @inPercentage INT ) AS BEGIN BEGIN TRY DECLARE @XMLAntes XML, @XMLDespues XML
SET @XMLAntes = (SELECT B.[Id], B.[RelationshipId], B.[PersonId], B.[SavingsAccountId], B.[Name], B.[Percentage], B.[Condition], B.[InsertAt], B.[InsertBy], B.[InsertIn] FROM Benefactor AS B WHERE B.Id = @inId FOR XML AUTO)
BEGIN TRANSACTION updateBenefactor EXEC SP_Update_Benefactor @inId, @inPercentage -- se hace el update --UpdateBenefactor SET @XMLDespues = (SELECT B.[Id], B.[RelationshipId], B.[PersonId], B.[SavingsAccountId], B.[Name], B.[Percentage], B.[Condition], B.[InsertAt], B.[InsertBy], B.[InsertIn] FROM Benefactor AS B WHERE B.Id = @inId FOR XML AUTO)
Se busco la manera de poder obtener unicamente el dia de una fecha para hacer el condicional de la fecha, se encontro que la funcion DAY() es muy util ya que extrae el dia de una fecha y puede ser comparada en multi-tipos es decir que no importa si se compara contra un varchar o un int siempre funcionara
Se agrega la ventana para poder realizar las consultas de administrador, en la misma ventana se mostraran las consultas una vez existan, y se seguirán mostrando hasta que se elija consulte otra cosa
Se conecto la funcionalidad de los events con la interfaz grafica, la razonn principal de la demora fue la dificultad para enviar el id de usuario por limitaciones del framework que se esta usando sin embargo se soluciono agregando un atributo "user" en el objeto "Benefactor" y "CuentaObjetivo" que se encuentran en el front end
export default class Benefactor{ id: number | undefined; nameDocId: string; savingsAccountId: number; valueDocIden: string; name: string; percentage: number; user: number | undefined; -> aqui esta el cambio importante
Ademas se experimentaron demoras por mal uso de las transacciones ya que le puse el mismo nombre al sp y a la transaccion y en un momento dado el motor de bases de datos se quedo en loop ya que no podia hacer comit de una transaccion y tampoco podia hacer rollback esto me demoro al menos 30 minutos
13/1/2021 Se completo el SP para realizar la consulta de administrador C. Se busco información con el fin de ver si se podía retornar elementos de una tabla en un orden especificado: https://www.w3schools.com/sql/sql_orderby.asp También se modifico el SP de la consulta B para que en lugar de retornar los Id de las cuentas retornara los códigos de las cuentas.
Se realizaron varios cambios en el diagrama de la base de datos, primero se elimino la tabla Tipo de Movimiento Interes, ya que en el xml brindado no venia ningun nodo que funcionara para llenar esa tabla por lo tanto se asume que sobra, tambien se borra la llave foranea que tenia esta tabla con la tabla MovimientoInteres, y se cambia el tipo de la columna, "fee" de la tabla movimiento interes ya que estaba en money y es necesario que este en float
Se encontro un error en el script principal que me atraso al rededor de 30 minutos y era esta simple linea
SET @minimo5 = @minimo5 + 1
la cual faltaba en el siguiente pedazo de codigo
WHILE @minimo5 <= @maximo5 BEGIN SELECT @fecha = OBJ.[EndDate], @cuentaPrinId = OBJ. [SavingsAccountId], @cuentaObjId = OBJ.[Id] FROM [dbo].[ObjetiveAccount] OBJ WHERE OBJ.Id = @minimo5
IF ((CAST( @fecha AS DATE) = CAST( @lo1 AS DATE))) BEGIN EXEC dbo.redencionCO @cuentaPrinId, @cuentaObjId, @lo1 END SET @minimo5 = @minimo5 + 1 >> esta linea faltaba END
La cual estaba ciclando el programa y no estaba dejando avanzar al script
Anteriormente Isaac habia realizado el sp para el calculo de intereses diarios sin embargo estabamos cometiendo el error de directamente sumar dichos intereses a la cuenta objetivo, cuando en realidad teniamos que esperar a la redencion de la cuenta para poder sumar esos intereses, ademas debido a ese error no estabamos usando la tabla Movimiento Intereses, por lo que debimos modificar el sp de interes diario para que se fuera actualizando en la tabla movimiento intereses el interes acumulado, una vez hecho esto solo quedaba modificar el sp de redencion de CO para que antes de hacer el traspaso de CO a Cuenta principal sumara los intereses
En un momento pense que tenia que verificar que en la tabla existiera algo sin embargo despues me di cuenta que bastaba con un EXISTS aun asi voy a poner el link de donde habia sacado el siguiente codigo
SELECT COUNT(*) AS RowCnt FROM yourTable
Este devolvia la cantidad de Rows de una tabla y con ello podia verificar si la tabla estaba vacia o no
Se logro implementar la consulta A de la ventana de administrador, sin embargo se reconocio un error en el stored procedure, cabe destacar que para poder implementar esta consulta se debio crear un objeto .ts en el front end en el cual se almacenan los resultados de las consultas, en el drive se adjunta un ejemplo de el primer intento de implementacion
Se logro implementar la consulta C ademas se modifico la clase Consultas.ts para poder reutilizarla con todas las consultas, la tecnica que se utilizo fue usar los atributos undefined asi si no hay ningun campo en el response que les haga match no se muestran y no ensucia la informacion de otra consulta, ademas se utlizo una variable de tipo para diferenciar cual de los 3 botones de consulta se utilizan, en un momento quise poner un boton de wipe pero no servia ya que seguia mostrando el card aunque vacio, se adjunta en las imagenes la clase Consultas.ts primero con los atributos para las consultas A y C y luego para los 3 tipos de consultas
Se termino de implementar la consulta B que era la que faltaba y se arreglo el stored procedure de la consulta A el error era que no se estaba haciendo update de el balance teorico, es decir faltaba esta linea
UPDATE [dbo].[AdminQueryA] SET [Balance] = @balanceQuery + @montoTransaccion, [Deposits] = [Deposits] + 1 WHERE [dbo].[AdminQueryA].[ObjetiveAccountId] = @idObjetivo
ya que solo se hacia update de el balance que si se pudo depositar sin embargo cuando se puede depositar hay que hacer update de ambas filas
15/1/2021 Se realizo una llamada con el fin de revisar si el proyecto funcionaba correctamente. Se detectaron varios errores de los cuales la mayoría fueron resueltos en la reunión. Ahora se debe de corregir las consultas de administrador B y C.
15/1/2021 Se corrigió el problema en la consulta de administrador C. El orden de una operación provocaba que un numero se interpretara como 0. Al cambiar el orden la operación se realiza correctamente. También las inserciones a una tabla catalogo se pusieron dentro del transaction.
INSERT INTO @TempDatosBeneficiarios (BeneficiarioId, PersonId, NombrePersona, NumeroCuenta, Balance) SELECT B.Id, P.Id, P.Name, SA.[AccountNumber], (SA.[Balance]*B.[Percentage])/100 FROM [dbo].[Benefactor] B INNER JOIN [dbo].[Person] P ON P.Id = B.[PersonId] INNER JOIN [dbo].[SavingsAccount] SA ON SA.Id = B.[SavingsAccountId] WHERE B.[Condition] = 1
SELECT * from @TempDatosBeneficiarios
SELECT @minimo1 = MIN(TDB.Sec), @maximo1 = MAX(TDB.Sec) FROM @TempDatosBeneficiarios TDB
Cuentas Objetivos: funcionan correctamente en base a las pruebas realizadas Bitácora de Cambios: funcionan correctamente en base a las pruebas realizadas Consultas de Administrador: funcionan correctamente en base a las pruebas realizadas
Se reviso varias veces el trabajo y se concluyo que se logro realizar todo lo especificado de manera correcta, ademas se agregaron al drive de fotos algunos graficos de los commits de github para poder visualizar mejor los cambios, junto con muchisimos screenshots de los diversos avances en el proyecto, tambien se agregaron las graficas de los post en la bitacora en el drive de fotos, finalmente cabe destacar que en este proyecto se pusieron a prueba todos los conocimientos acumulados hasta el momento y que en retrospectiva fue un proyecto simple sin embargo existieron varias ocasiones en las que surgieron problemas que llegaron a retrasar mucho la implementacion del trabajo.
12-21-2020
ResponderEliminarPrimera reunion para comentar el pdf de la progra, repasamos todos los puntos y dividimos la carga, surgieron varias dudas que evacuaremos en los proximos dias, tambien creamos las nuevas tablas y comentamos que debiamos arreglar segun la revision de la progra pasada, ademas creamos un nuevo blog de bitacoras y esperamos ser mas profesionales en este
Tiempo estimado: 1 hora
12/22/2020
ResponderEliminarSe intercambio el orden de los update e insert para que los insert estuviesen por encima de los updates. Se modifico la forma en la que se cuentan las operaciones de retiros de ATM y humano. Se sustituyeron algunos select por if. También se agrego el la tabla para el manejo de errores y el código para insertar en esta tabla.
Tiempo estimado: 40 min
INSERT INTO dbo.BE_DBErrors VALUES (
EliminarSUSER_SNAME(),
ERROR_NUMBER(),
ERROR_STATE(),
ERROR_SEVERITY(),
ERROR_LINE(),
ERROR_PROCEDURE(),
ERROR_MESSAGE(),
GETDATE()
);
12/23/2020
ResponderEliminarSe agregaron los TRANSACTION al SP de cerrado de estados de cuenta y al trigger para crear un estado de cuenta para, a este trigger también se le agrego el manejo de errores. Se utilizo el READ COMMITTED por estándar del curso.
BEGIN TRY
EliminarSET TRANSACTION ISOLATION LEVEL READCOMMITED;
BEGIN TRANSACTION nombreTransaccion
Cosas por hacer
COMMIT TRANSACTION nombreTransaccion;
END TRY
BEGIN CATCH
IF @@TRANCOUNT>0
ROLLBACK TRANSACTION nombreTransaccion;
END CATCH
12/25/2020
ResponderEliminarSe creo el trigger "triggerEventInsertBenefactor" el cual se activa cuando se inserta un benefactor. Inserta un evento en la tabla Event.
Tiempo estimado: 40 min
12/29/2020
ResponderEliminarNos reunimos para hablar sobre el proyecto y discutir posibles formas de trabajarlo.
Tiempo estimado: 35 min
12-30-2020
ResponderEliminarIsaac me dio un machote que tenia la informacion para insertar eventos, con estos adapte los cruds tanto de objetive account como de benefactor, para que al ser llamados funcione la insercion del evento y la accion a la que corresponde el evento, falta hacer pruebas para buscar fallos pero de primera mano no se ven errores
Tiempo Estimado(Mario): 1 hora
Tiempo Estimado(Isaac): 40 min
Machote de Isaac
Eliminar@inId INT,
@inUsuario INT
BEGIN TRY
DECLARE @XMLAntes XML,
@XMLDespues XML
SET @XMLAntes = (SELECT B.[Id],
B.[RelationshipId],
B.[PersonId],
B.[SavingsAccountId],
B.[Name],
B.[Percentage],
B.[Condition],
B.[InsertAt],
B.[InsertBy],
B.[InsertIn]
FROM Benefactor AS B
WHERE B.Id = @inId
FOR XML AUTO)
BEGIN TRANSACTION updateBenefactor
--UpdateBenefactor
SET @XMLDespues = (SELECT B.[Id],
B.[RelationshipId],
B.[PersonId],
B.[SavingsAccountId],
B.[Name],
B.[Percentage],
B.[Condition],
B.[InsertAt],
B.[InsertBy],
B.[InsertIn]
FROM Benefactor AS B
WHERE B.Id = @inId
FOR XML AUTO)
INSERT INTO [dbo].[Event](TypeEventId,
UserId,
IP,
eventDate,
xmlBefore,
xmlAfter)
SELECT 2,
@inUsuario,
CONVERT(char(15), CONNECTIONPROPERTY('client_net_address')),
GETDATE(),
@XMLAntes,
@XMLDespues
COMMIT TRANSACTION updateBenefactor;
END TRY
BEGIN CATCH
IF @@TRANCOUNT>0
ROLLBACK TRANSACTION updateBenefactor;
INSERT INTO [dbo].[BE_Errors] VALUES (
SUSER_SNAME(),
ERROR_NUMBER(),
ERROR_STATE(),
ERROR_SEVERITY(),
ERROR_LINE(),
ERROR_PROCEDURE(),
ERROR_MESSAGE(),
GETDATE()
);
END CATCH
Modificaciones de mario
EliminarCREATE PROCEDURE updateBenefactor(
@inId INT,
@inUsuario INT,
@inPercentage INT
)
AS
BEGIN
BEGIN TRY
DECLARE @XMLAntes XML,
@XMLDespues XML
SET @XMLAntes = (SELECT B.[Id],
B.[RelationshipId],
B.[PersonId],
B.[SavingsAccountId],
B.[Name],
B.[Percentage],
B.[Condition],
B.[InsertAt],
B.[InsertBy],
B.[InsertIn]
FROM Benefactor AS B
WHERE B.Id = @inId
FOR XML AUTO)
BEGIN TRANSACTION updateBenefactor
EXEC SP_Update_Benefactor @inId, @inPercentage -- se hace el update
--UpdateBenefactor
SET @XMLDespues = (SELECT B.[Id],
B.[RelationshipId],
B.[PersonId],
B.[SavingsAccountId],
B.[Name],
B.[Percentage],
B.[Condition],
B.[InsertAt],
B.[InsertBy],
B.[InsertIn]
FROM Benefactor AS B
WHERE B.Id = @inId
FOR XML AUTO)
INSERT INTO [dbo].[Event](TypeEventId,
UserId,
IP,
eventDate,
xmlBefore,
xmlAfter)
SELECT 2,
@inUsuario,
CONVERT(char(15), CONNECTIONPROPERTY('client_net_address')),
GETDATE(),
@XMLAntes,
@XMLDespues
COMMIT TRANSACTION updateBenefactor;
END TRY
BEGIN CATCH
IF @@TRANCOUNT>0
ROLLBACK TRANSACTION updateBenefactor;
INSERT INTO [dbo].[BE_Errors] VALUES (
SUSER_SNAME(),
ERROR_NUMBER(),
ERROR_STATE(),
ERROR_SEVERITY(),
ERROR_LINE(),
ERROR_PROCEDURE(),
ERROR_MESSAGE(),
GETDATE()
);
END CATCH
END
GO
1-07-2020
ResponderEliminarSe busco la manera de poder obtener unicamente el dia de una fecha para hacer el condicional de la fecha, se encontro que la funcion DAY() es muy util ya que extrae el dia de una fecha y puede ser comparada en multi-tipos es decir que no importa si se compara contra un varchar o un int siempre funcionara
Tiempo estimado: 20 min
Ejemplo con '15' en varchar
EliminarDECLARE @a DATE = '12-15-2020'
IF (DAY(@a) = '15')
BEGIN
SELECT 'Entro'
END
ELSE
BEGIN
SELECT 'NO ENTRO'
END
Ejemplo con 15 en int
EliminarDECLARE @a DATE = '12-15-2020'
IF (DAY(@a) = 15)
BEGIN
SELECT 'Entro'
END
ELSE
BEGIN
SELECT 'NO ENTRO'
END
en ambos casos el output es 'Entro'
07-1-2020
ResponderEliminarSe agrega la opcion para poder ingresar como administrador para hacer las consultas especializadas
Tiempo estimado: 20 min
En el siguiente link se pueden observar las imagenes con el antes y el despues es decir una carpeta de apendices
EliminarLink: https://drive.google.com/drive/folders/1D9NODhGjL3_5KWn-NcIbLy9sywmrJN91?usp=sharing
07-1-2020
ResponderEliminarSe agrega la ventana para poder realizar las consultas de administrador, en la misma ventana se mostraran las consultas una vez existan, y se seguirán mostrando hasta que se elija consulte otra cosa
Tiempo estimado: 1 hora
En la carpeta de drive se suben las etapas del proceso
Eliminar07-1-2020
ResponderEliminarSe conecto la funcionalidad de los events con la interfaz grafica, la razonn principal de la demora fue la dificultad para enviar el id de usuario por limitaciones del framework que se esta usando sin embargo se soluciono agregando un atributo "user" en el objeto "Benefactor" y "CuentaObjetivo" que se encuentran en el front end
export default class Benefactor{
id: number | undefined;
nameDocId: string;
savingsAccountId: number;
valueDocIden: string;
name: string;
percentage: number;
user: number | undefined; -> aqui esta el cambio importante
Tiempo estimado: 2 horas
Ademas se experimentaron demoras por mal uso de las transacciones ya que le puse el mismo nombre al sp y a la transaccion y en un momento dado el motor de bases de datos se quedo en loop ya que no podia hacer comit de una transaccion y tampoco podia hacer rollback esto me demoro al menos 30 minutos
Eliminar11/1/2021
ResponderEliminarSe completo el SP para realizara la consulta de administrador B. Aun se necesita realizar pruebas y conectarlo con la interfaz.
Tiempo estimado: 2 horas
13/1/2021
ResponderEliminarSe completo el SP para realizar la consulta de administrador C. Se busco información con el fin de ver si se podía retornar elementos de una tabla en un orden especificado: https://www.w3schools.com/sql/sql_orderby.asp
También se modifico el SP de la consulta B para que en lugar de retornar los Id de las cuentas retornara los códigos de las cuentas.
Tiempo estimado: 2 horas
13-1-2021
ResponderEliminarSe agrego el manejo de errores a todos los scripts que no lo tenian
Tiempo estimado: 15 min
13-1-2021
ResponderEliminarSe realizaron varios cambios en el diagrama de la base de datos, primero se elimino la tabla Tipo de Movimiento Interes, ya que en el xml brindado no venia ningun nodo que funcionara para llenar esa tabla por lo tanto se asume que sobra, tambien se borra la llave foranea que tenia esta tabla con la tabla MovimientoInteres, y se cambia el tipo de la columna, "fee" de la tabla movimiento interes ya que estaba en money y es necesario que este en float
Tiempo estimado: 30 min
13-1-2021
ResponderEliminarSe encontro un error en el script principal que me atraso al rededor de 30 minutos y era esta simple linea
SET @minimo5 = @minimo5 + 1
la cual faltaba en el siguiente pedazo de codigo
WHILE @minimo5 <= @maximo5
BEGIN
SELECT @fecha = OBJ.[EndDate],
@cuentaPrinId = OBJ. [SavingsAccountId],
@cuentaObjId = OBJ.[Id]
FROM [dbo].[ObjetiveAccount] OBJ
WHERE OBJ.Id = @minimo5
IF ((CAST( @fecha AS DATE) = CAST( @lo1 AS DATE)))
BEGIN
EXEC dbo.redencionCO @cuentaPrinId, @cuentaObjId, @lo1
END
SET @minimo5 = @minimo5 + 1 >> esta linea faltaba
END
La cual estaba ciclando el programa y no estaba dejando avanzar al script
Tiempo estimado: 30 min
13-1-2021
ResponderEliminarAnteriormente Isaac habia realizado el sp para el calculo de intereses diarios sin embargo estabamos cometiendo el error de directamente sumar dichos intereses a la cuenta objetivo, cuando en realidad teniamos que esperar a la redencion de la cuenta para poder sumar esos intereses, ademas debido a ese error no estabamos usando la tabla Movimiento Intereses, por lo que debimos modificar el sp de interes diario para que se fuera actualizando en la tabla movimiento intereses el interes acumulado,
una vez hecho esto solo quedaba modificar el sp de redencion de CO para que antes de hacer el traspaso de CO a Cuenta principal sumara los intereses
Tiempo estimado: 30 min
EliminarEn un momento pense que tenia que verificar que en la tabla existiera algo sin embargo despues me di cuenta que bastaba con un EXISTS aun asi voy a poner el link de donde habia sacado el siguiente codigo
SELECT COUNT(*) AS RowCnt
FROM yourTable
Este devolvia la cantidad de Rows de una tabla y con ello podia verificar si la tabla estaba vacia o no
Link: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/5bbe7be9-a212-4712-9e7b-58d02244b7dd/how-to-check-if-a-table-is-empty-using-query-code?forum=sqlexpress#:~:text=Hello%2C,return%200%20%3D%20count%20of%20rows.
13-1-2021
ResponderEliminarSe termino de el sp de redencion de CO de manera que funcione correctamente, solo hacia falta unos pequenos cambios para hacer un update y un select
Tiempo estimado: 10 min
14-1-2021
ResponderEliminarSe logro implementar la consulta A de la ventana de administrador, sin embargo se reconocio un error en el stored procedure, cabe destacar que para poder implementar esta consulta se debio crear un objeto .ts en el front end en el cual se almacenan los resultados de las consultas, en el drive se adjunta un ejemplo de el primer intento de implementacion
Tiempo estimado: 1:30 min
14-1-2021
ResponderEliminarSe logro implementar la consulta C ademas se modifico la clase Consultas.ts para poder reutilizarla con todas las consultas, la tecnica que se utilizo fue usar los atributos undefined asi si no hay ningun campo en el response que les haga match no se muestran y no ensucia la informacion de otra consulta, ademas se utlizo una variable de tipo para diferenciar cual de los 3 botones de consulta se utilizan, en un momento quise poner un boton de wipe pero no servia ya que seguia mostrando el card aunque vacio, se adjunta en las imagenes la clase Consultas.ts primero con los atributos para las consultas A y C y luego para los 3 tipos de consultas
Tiempo estimado: 2 horas
Aun existe un error en el stored procedure de la consulta A una vez se termine de implementar la consulta C se arreglara dicho error
EliminarSe termino de implementar la consulta B que era la que faltaba y se arreglo el stored procedure de la consulta A el error era que no se estaba haciendo update de el balance teorico, es decir faltaba esta linea
EliminarUPDATE [dbo].[AdminQueryA] SET [Balance] = @balanceQuery + @montoTransaccion,
[Deposits] = [Deposits] + 1
WHERE [dbo].[AdminQueryA].[ObjetiveAccountId] = @idObjetivo
ya que solo se hacia update de el balance que si se pudo depositar sin embargo cuando se puede depositar hay que hacer update de ambas filas
15/1/2021
EliminarSe realizo una llamada con el fin de revisar si el proyecto funcionaba correctamente. Se detectaron varios errores de los cuales la mayoría fueron resueltos en la reunión. Ahora se debe de corregir las consultas de administrador B y C.
Tiempo estimado: 40 minutos
Este comentario ha sido eliminado por el autor.
Eliminar15/1/2021
ResponderEliminarSe corrigió el problema en la consulta de administrador C. El orden de una operación provocaba que un numero se interpretara como 0. Al cambiar el orden la operación se realiza correctamente. También las inserciones a una tabla catalogo se pusieron dentro del transaction.
Tiempo estimado: 15 minutos
INSERT INTO @TempDatosBeneficiarios (BeneficiarioId,
EliminarPersonId,
NombrePersona,
NumeroCuenta,
Balance)
SELECT B.Id,
P.Id,
P.Name,
SA.[AccountNumber],
(SA.[Balance]*B.[Percentage])/100
FROM [dbo].[Benefactor] B
INNER JOIN [dbo].[Person] P ON P.Id = B.[PersonId]
INNER JOIN [dbo].[SavingsAccount] SA ON SA.Id = B.[SavingsAccountId]
WHERE B.[Condition] = 1
SELECT * from @TempDatosBeneficiarios
SELECT @minimo1 = MIN(TDB.Sec),
@maximo1 = MAX(TDB.Sec)
FROM @TempDatosBeneficiarios TDB
El "SELECT *" se eliminó de la versión que se subió al github.
Eliminar20/1/2021
ResponderEliminarSe corrigió la consulta de administrador B. Los cambios se subieron al git.
Tiempo estimado: 30 minutos
ResponderEliminarCuentas Objetivos: funcionan correctamente en base a las pruebas realizadas
Bitácora de Cambios: funcionan correctamente en base a las pruebas realizadas
Consultas de Administrador: funcionan correctamente en base a las pruebas realizadas
Se reviso varias veces el trabajo y se concluyo que se logro realizar todo lo especificado de manera correcta, ademas se agregaron al drive de fotos algunos graficos de los commits de github para poder visualizar mejor los cambios, junto con muchisimos screenshots de los diversos avances en el proyecto, tambien se agregaron las graficas de los post en la bitacora en el drive de fotos, finalmente cabe destacar que en este proyecto se pusieron a prueba todos los conocimientos acumulados hasta el momento y que en retrospectiva fue un proyecto simple sin embargo existieron varias ocasiones en las que surgieron problemas que llegaron a retrasar mucho la implementacion del trabajo.
Horas trabajadas:
Mario: 11.75 horas
Isaac: 9 horas