FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Pues no, no salí corriendo
Está interesante la discusión, pero tengo que apuntar que sí que necesito calcular el saldo parcial para cada registro, al estilo de un extracto bancario, ya que lo utilizo para comparar en cada apunte si me coincide el saldo que yo tengo con el saldo que calcula el banco. Además el orden de introducción de los apuntes no es necesariamente ordenado, ya que a veces puedo insertar un registro antes que otros que ya tenían calculado su correspondiente saldo, con lo cual me tocar recalcular los posteriores. Sigo dándole vueltas al tema, pero aún no he encontrado una solución satisfactoria. Gracias por vuestro interes |
#2
|
|||
|
|||
Era lo que decía en apartado B), puede haber una situación que justifique ese campo.
Bien, si tenés un campo fecha, como supongo, al insertar el registro queda al último del grupo de registros de su misma fecha, ¿no?. Probaste: 1) Calcular saldo HASTA ese día con select last 1 saldo where fecha < TuFecha order by fecha desc (hacé un índice desc para facilitarle las cosas al motor) Ahí tenés rápidamente el saldo anterior. Luego 2) Recalcular saldos posteriores: UPDATE Cuenta SET Saldo = Haber - Debe + [SaldoAnt] where fecha >= TuFecha Que actualiza todos los registros subsiguientes al cálculo del saldo. [SaldoAnt] es UNA SUMA FIJA que le agregas a la instrucción que surge del primer select. Lo probé y funciona. Luego de cada insert o update o delete, ejecutás estas dos, y debería funcionar (al menos sí me anduvo en FireBird). Suerte |
#3
|
|||
|
|||
Fé de erratas:
el primer select es select FIRST 1 saldo where fecha < TuFecha order by fecha desc o select last 1 saldo where fecha < TuFecha order by fecha |
#4
|
|||
|
|||
Ya sé, tampoco anda. Por qué no le preguntás a Kinobi?
|
#5
|
||||
|
||||
Insisto en lo innecesario de añadir un campo saldo.
Como ya ha aclarado mazinger, requiere mostrar los saldos parciales de manera que de cualquier forma los registros correspondientes deben bajarse, y de ahí a calcular el saldo es muy fácil y rápido. El mismo ha mencionado el hecho de que al no tener insertados los registros en orden (cronológico supongo) tiene que recalcular el saldo así que ¿para qué estarse liando con una actualización innecesaria de un campo calculado, es decir, justamente un campo cuyo valor se obtiene del cálculo de otros campos? // Saludos |
#6
|
|||
|
|||
Una sola consulta T-SQL
Hola compañeros, hace poco busqué la respuesta a la pregunta planteada en este tema pero no encontré respuestas muy satisfactorias para mi gusto, así que les planteo una solución en T-SQL que calcula el saldo en una sola consulta. Se que este tema se incluyó hace varios años, pero siempre habemos programadores nuevos que intentamos resolver viejos problemas cierto?.. espero que le sirva a alguien.
Comensaré diciendo que tengo dos tabla llamadas TComprobante y detalle_comprobante, que creo que se explican por si mismas, cada una tiene, obviamente, un campo identidad que, en el caso del detalle_comprobante, se aprovecha para calcular el saldo hasta el registro indicado. Despliega el siguiente resultado (dependiendo de lo que tenga en las tablas claro). NROCOMP FECHA DESCRIPCION INGRESO EGRESO SALDO 099 02/01/2012 Aporte Regular.........100.00 00.00 100.00 109 03/01/2012 Retiro de Ap.Regular ...0.00 11.00 89.00 109 03/01/2012 Ptmo.Corriente .........21.00 00.00 110.00 Debe tomarse en cuenta de NROCOMP no es la llave de la tabla TComprobante ni de Detalle_comprobante, es solo un otro dato. Resalto la capacidad de Transact de SQL Server 2000 de poder anidad una consulta dentro e otra permitiendo utilizar los valores de los registros para de alguna manera parametrizar la consulta anidada. Si no se utiliza Order By d.iddetcomp el saldo se calcula bien de igual manera. Se puede incluir parametrización entre fechas, cuentas específicas, etc, todo depende de lo que se necesite visualizar. Un Saludo. Última edición por Casimiro Notevi fecha: 12-06-2012 a las 23:36:51. |
|
|
|