viernes, 5 de mayo de 2017
5/5/2017
El miembro del grupo Sebastian se enfermó, lo cual le impidió fuertemente sus posibilidades de trabajar en el proyecto. Nos pusimos a pasar la base de datos de una computadoira, a la compu en la que se va a presentar el proyecto. Investigamos de cómo se crea una página web desde visual studio para conectarla con la base de datos y tener las conexiones disponibles. Se creó una página web asp.net en c# visual studio y efectivamente e pudo conectar a la base de datos del proyecto. Se editó la interfaz de esta página web y se probó que efectivamente funcionara varias veces. Lo que por el momento está faltando es darle funcionalidad a la página web, ya que los procesos necesarios ya están creados, pero hay que implementarlos en la página. Aproximadamente 16h de trabajo
Día 14: 2/5/2017
(8:20am) Continuamos trabajando en la progra, nos enfocamos en conectar la inserción de los cada movimiento con la cuenta y el EstadoCuenta, ya que modifican el saldo actual, final y mínimo durante el mes.
(8:45am) Separaremos las modificaciones sobre el cierre de cuenta, de manera que cada una (multas, cargos, intereses) genere un reporte (movimiento) al respecto.
(10:00am) El separar las modificaciones, así como el generar los respectivos movimientos nos tomó más tiempo del esperado.
(10:20am) Creemos que tenemos listo el procedimiento masivo, sin embargo no tenemos tiempo para probarlo ya que se perdería mucho tiempo borrando los 3150 movimientos. Suspendemos labores para intentar conseguir una entrada para el show.
(12:30pm) Regresamos. La bitácora sigue sin funcionar, por lo que obtamos por establecer un "respaldo" en WordPad mientras se soluciona.
(1:00pm) Procederemos a realizar el procedimiento sobre las subcuentas.
(1:00pm) Ya funciona la página de la bitácora
(2:00pm) Debemos modificar la inserción de Beneficiarios desde XML para que se relacione con una persona.
(2:50pm) Se probó con todo y movimientos, procedemos a analizar los datos para ver si funciona.
(3:10pm) Seguimos borrando datos, el cierre de cuentas no se efectuó.
(5:10pm) Ya sirve el procedimiento masivo para los estados de cuenta (cerrar e iniciar, así como la asignación de cargos e intereses.
(5:15pm) Vamos a intentar copiar la base de datos a la computadora de Dennis.
(8:45am) Separaremos las modificaciones sobre el cierre de cuenta, de manera que cada una (multas, cargos, intereses) genere un reporte (movimiento) al respecto.
(10:00am) El separar las modificaciones, así como el generar los respectivos movimientos nos tomó más tiempo del esperado.
(10:20am) Creemos que tenemos listo el procedimiento masivo, sin embargo no tenemos tiempo para probarlo ya que se perdería mucho tiempo borrando los 3150 movimientos. Suspendemos labores para intentar conseguir una entrada para el show.
(12:30pm) Regresamos. La bitácora sigue sin funcionar, por lo que obtamos por establecer un "respaldo" en WordPad mientras se soluciona.
(1:00pm) Procederemos a realizar el procedimiento sobre las subcuentas.
(1:00pm) Ya funciona la página de la bitácora
(2:00pm) Debemos modificar la inserción de Beneficiarios desde XML para que se relacione con una persona.
(2:50pm) Se probó con todo y movimientos, procedemos a analizar los datos para ver si funciona.
(3:10pm) Seguimos borrando datos, el cierre de cuentas no se efectuó.
(5:10pm) Ya sirve el procedimiento masivo para los estados de cuenta (cerrar e iniciar, así como la asignación de cargos e intereses.
(5:15pm) Vamos a intentar copiar la base de datos a la computadora de Dennis.
lunes, 1 de mayo de 2017
Día 13: 1/5/2017
(4:00pm) Continuamos tra ba jando
(5:00pm) Se insertan correctamente las subcuentas, tomamos una pausa.
(6:50pm) Regresamos del descanso, procedemos a realizar el SP masivo de cierres de cuenta
(7:20pm) El procedimiento masivo de cálculo de intereses y cierre de cuenta se ejecutará dentro del ciclo de carga datos. Utilizaremos el https://www.w3schools.com/sql/func_datepart.asp para obtener el día de una fecha y así comparar el día cierre de una cuenta.
(7:30pm) Se opta por establecer 3 condiciones para saber si se trata de un mes que finaliza en 28, 30 o 31.
(8:40pm) Nos damos cuenta que los movimientos insertados no han modificado el Estado de Cuenta :-/
(10:00pm) El codigo del procedimiento masivo es muy extenso y complicado, tratamos de no separarlo en multiples SP ya que no tenemos tanto tiempo
(11:00pm) http://stackoverflow.com/questions/10012695/sql-statement-using-where-clause-with-multiple-values nos ayudó a condicionar el procedimiento para un mes de 30 días, a pesar de que el código es muy similar, y puede ser optimizado muy fácilmente para evitar tantas lineas (mediante la implementacion de una bandera o dos banderas, por ejemplo)
(11:30pm) Se "termina" el SP masivo para el "cerrado" de Estados de Cuenta, sin embargo no tienen muchas validaciones, entre ellas los transaction. Continuaremos mañana temprano.
Aproximadamente 5 horas y media
(5:00pm) Se insertan correctamente las subcuentas, tomamos una pausa.
(6:50pm) Regresamos del descanso, procedemos a realizar el SP masivo de cierres de cuenta
(7:20pm) El procedimiento masivo de cálculo de intereses y cierre de cuenta se ejecutará dentro del ciclo de carga datos. Utilizaremos el https://www.w3schools.com/sql/func_datepart.asp para obtener el día de una fecha y así comparar el día cierre de una cuenta.
(7:30pm) Se opta por establecer 3 condiciones para saber si se trata de un mes que finaliza en 28, 30 o 31.
(8:40pm) Nos damos cuenta que los movimientos insertados no han modificado el Estado de Cuenta :-/
(10:00pm) El codigo del procedimiento masivo es muy extenso y complicado, tratamos de no separarlo en multiples SP ya que no tenemos tanto tiempo
(11:00pm) http://stackoverflow.com/questions/10012695/sql-statement-using-where-clause-with-multiple-values nos ayudó a condicionar el procedimiento para un mes de 30 días, a pesar de que el código es muy similar, y puede ser optimizado muy fácilmente para evitar tantas lineas (mediante la implementacion de una bandera o dos banderas, por ejemplo)
(11:30pm) Se "termina" el SP masivo para el "cerrado" de Estados de Cuenta, sin embargo no tienen muchas validaciones, entre ellas los transaction. Continuaremos mañana temprano.
Aproximadamente 5 horas y media
domingo, 30 de abril de 2017
Día 12: 30/4/2017
(12:00md) Se nos ocurrió separar una condición para así evitar el uso de IS NOT NULL, esperamos con esto se nos arregle el error.
(12:15pm) Borramos los datos que se cargaron anoche y procedemos a reiniciar los IDENTITY de las tablas. http://stackoverflow.com/questions/21824478/reset-identity-seed-after-deleting-records-in-sql-server
(1:00pm) Ahora inserta todos los movimientos hasta la fecha en que se solicita por ejemplo: [1],[1,2],[1,2,3],..., representando cada número el ID del movimiento en la tabla temporal.
(5:00pm) Regresamos a las labores sobre la progra.
(5:20pm) Logramos insertar las cuentas
(7:00pm) Luego de celebrar que ya no da ese extraño error, procedimos a procesar movimientos, sin embargo nos damos cuenta que al crear (insertar) las cuentas, debimos de haber creado un estado de cuenta para cada una.
(8:50pm) Tenemos un problema para obtener el día actual para los PostTime
(9:30pm) Se logra poner a prueba exitosamente el cargador de movimientos
(9:50pm) Estamos borrando datos de las tablas para poder realizar nuevas pruebas.
(10:40pm) Tras lograr borrar los datos de la ultima prueba, la computadora se queda muy pegada, por lo que tocará reiniciarla.
(11:30pm) Retomamos la progra.
(1:00am) Analizando el modelo, optamos por eliminar las columnas de Beneficiarios de la tabla Cuenta, ya que estos podrían variar en cantidad y periodo, por lo que generarían nulos que suelen dar errores. Para contrarestar, le incluimos un FK de la cuenta al Beneficiario, de manera que se pueda llevar el control sobre estos de esta forma. Además, se pierde o se desconoce la importancia del valorID de Beneficiario, ya que el ID proporcionado pertenece al dueño de la cuenta.
(1:50am) Procedemos a probar el código de carga para Beneficiarios
(2:40am) Se avanzó poco con el código de lectura de las Subcuentas debido al cansancio.
Aproximadamente 10h
(12:15pm) Borramos los datos que se cargaron anoche y procedemos a reiniciar los IDENTITY de las tablas. http://stackoverflow.com/questions/21824478/reset-identity-seed-after-deleting-records-in-sql-server
(1:00pm) Ahora inserta todos los movimientos hasta la fecha en que se solicita por ejemplo: [1],[1,2],[1,2,3],..., representando cada número el ID del movimiento en la tabla temporal.
(5:00pm) Regresamos a las labores sobre la progra.
(5:20pm) Logramos insertar las cuentas
(7:00pm) Luego de celebrar que ya no da ese extraño error, procedimos a procesar movimientos, sin embargo nos damos cuenta que al crear (insertar) las cuentas, debimos de haber creado un estado de cuenta para cada una.
(8:50pm) Tenemos un problema para obtener el día actual para los PostTime
(9:30pm) Se logra poner a prueba exitosamente el cargador de movimientos
(9:50pm) Estamos borrando datos de las tablas para poder realizar nuevas pruebas.
(10:40pm) Tras lograr borrar los datos de la ultima prueba, la computadora se queda muy pegada, por lo que tocará reiniciarla.
(11:30pm) Retomamos la progra.
(1:00am) Analizando el modelo, optamos por eliminar las columnas de Beneficiarios de la tabla Cuenta, ya que estos podrían variar en cantidad y periodo, por lo que generarían nulos que suelen dar errores. Para contrarestar, le incluimos un FK de la cuenta al Beneficiario, de manera que se pueda llevar el control sobre estos de esta forma. Además, se pierde o se desconoce la importancia del valorID de Beneficiario, ya que el ID proporcionado pertenece al dueño de la cuenta.
(1:50am) Procedemos a probar el código de carga para Beneficiarios
(2:40am) Se avanzó poco con el código de lectura de las Subcuentas debido al cansancio.
Aproximadamente 10h
Día 11.2: 29/4/2017
(10:00pm) Continuamos trabajando en la interfaz (página) y el error.
(11:30pm) La computadora se pegó por lo que nos fuimos a dormir.
Aproximadamente una hora y 15 minutos
(11:30pm) La computadora se pegó por lo que nos fuimos a dormir.
Aproximadamente una hora y 15 minutos
sábado, 29 de abril de 2017
Día 11: 29/4/2017
(11:30am) Continuamos trabajando.
(2:00pm) A eso de la 1:30 intentamos correr un query que hizo que la computadora se pegara y dejara de responder, hasta que nos vimos forzados a reiniciarla manualmente.
(3:40pm) Tenemos el problema de que se inserta n-m veces cada cuenta, además de errores de n-(n-m) veces intentos de insertar. En otras palabras, intenta insertar aproximadamente 22 veces cada cuenta, de las cuales algunas lo logra y otras da error.
Aproximadamente 4h de trabajo (sufriendo con ese error la mayoría del tiempo)
(2:00pm) A eso de la 1:30 intentamos correr un query que hizo que la computadora se pegara y dejara de responder, hasta que nos vimos forzados a reiniciarla manualmente.
(3:40pm) Tenemos el problema de que se inserta n-m veces cada cuenta, además de errores de n-(n-m) veces intentos de insertar. En otras palabras, intenta insertar aproximadamente 22 veces cada cuenta, de las cuales algunas lo logra y otras da error.
Aproximadamente 4h de trabajo (sufriendo con ese error la mayoría del tiempo)
Día 9.2 y Día 10
Día 9.2: Trabajamos cerca de una hora, el jueves 27/4/2017, se logró adelantar bastante la inserción de personas.
Día 10 (28/4/2017): Se trabajaron 3 horas. Se terminó de insertar personas y se adelantó la inserción de cuentas, ambos a partir de las tablas temporales.
Total aproximado: 4 horas
Día 10 (28/4/2017): Se trabajaron 3 horas. Se terminó de insertar personas y se adelantó la inserción de cuentas, ambos a partir de las tablas temporales.
Total aproximado: 4 horas
Suscribirse a:
Comentarios (Atom)